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

Reply via email to