Hi,
First you wrongly used hb_gcRefDec() instead of hb_gcRefFree().
hb_gcRefDec() does not free allocated block. It only decrease
number of reference counters. If you do not have any cross
references then this block will be cleanly freed on next GC
collect call. If you have such references then it may cause
RT error ("Reference to freed block"). So you should use pair
of functions: hb_gcRefInc()/hb_gcRefFree().
I do not think that hb_gcRefDec() is necessary for any 3-rd party
code. It's not even used in current core code so probably I should
remove it to not confuse users and maybe add:
#define hb_gcRefDec hb_gcRefFree
to hbapi.h.
The new GC extensions opens door for some interesting extensions
in none core code so maybe it's time to make hb_gcRefInc() and
hb_gcRefFree() public functions though I'm not sure how many people
will have enough knowledge to use it without breaking some internals.
I think these should be made public (otherwise ugly #define
_API_INTERNAL_ is required in code).
hb_gcRefDec()/hb_gcRefFree() really confuses users. Function naming
makes think that hb_gcRefInc() and hb_gcRefDec() are the pair, and
hb_gcRefFree() should have a pair hb_gcRefAlloc(). Maybe name
hb_gcRefDecFree() would be a better name. Making hb_gcRefDec() to have
functionality of hb_geRefFree() will also be good (but do not add both
hb_gcRefDec() and hb_gcRefFree() with the same functionality - redundant
names also confuses). Leaving the current names would be also good if
only hb_gcRefInc() and hb_gcRefFree() will be moved to a public API.
Regards,
Mindaugas
P.S. I'll have more questions on GC, but I should try to make things
clear myself before asking you.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
