Hi,
Viktor Szakáts wrote:
2009-12-08 13:39 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbcairo/core.c
+ Enabled HB_USE_ITEM mode which doesn't use Harbour internals.
Viktor, I do not think this is a good commit before questions about GC API are
finally solved.
As per Przemek's last commit, both versions work now
equally well, both versions are equal in length,
but non-internal is much easier to understand,
The "non-internal" version is more *difficult* to understand.
To understand it you must know how collectible pointers are stored in
items, you must know that does "locked item" means. Do you know why
hb_gcUnlock() is used, what will go wrong if it will not be used? Why GC
marking will be redundant without hb_gcUnlock()?
Maybe I'm missing something but I fail to see why internal
version should be used at this point. Does it give much
more performance?
This is not a speed question here. For me usage of GC reference counter
is more clear than usage of extra item to force keeping GC block
unreleased. In "non-internal" version we have references:
iterator -> item -> path
otherwise:
iterator -> path
This extra item is not useful by itself. The whole C code operates on
path, these is no interfacing to .prg level here. We do not need an item
here, we need path only. In this case this extra item is just a
workaround to keep path reference counter increased instead of direct
hb_gcRefInc() call.
I want to see the second version (without extra item) working by default
in the final code, but I want to leave HB_USE_ITEM define, to make users
have a sample of various ways to cross-reference GC blocks. They can see
both of versions, compare it and understand how things work.
Regards,
Mindaugas
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
