[Gtkradiant] [Bug 264] add incref macros and documentation

[gtkradiant@zerowing.idsoftware.com]

http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=264

ttimo@idsoftware.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Platform|                            |All



------- Additional Comments From ttimo@idsoftware.com  2001-11-28 10:53 -------
some reflexion material

<TTimo> now I remember why I don't want to have the default refcount to 1
<TTimo> because you have to worry about what each function does to use this properly
<TTimo> i.e. between an API function that does CreateObject and one that does
SearchObject
<TTimo> on something returned by CreateObject, if you don't keep it you will
call DecRef
<TTimo> on SearchObject you will not DecRef since it's only a search and you're
on your own to IncRef if you keep the object
<TTimo> that introduces a nasty case-by-case situation when dealing with
reference counting, and that's also why reference counting is done so badly in
the shader code
<SmallPileofGibs> i think you should decref something you get from searchobject
<SmallPileofGibs> because you're being given a reference
<SmallPileofGibs> hrm
<SmallPileofGibs> yeah, that would be the only way to keep things consistent
really..
<SmallPileofGibs> unless you get a const * from searchobject
<SmallPileofGibs> in which case you wouldn't be able to call decref
<SmallPileofGibs> so the refcount shouldn't be incremented by searchobject
<TTimo> saying that anything that does refcount returned by a function call
should be decref'ed if you don't keep it doesn't sound like a good solution
<SmallPileofGibs> it depends what you expect searchobject to do
<TTimo> that's what I'm saying, if you rely on each function you use to decide
your decref strategy, it doesn't work
<SmallPileofGibs> why not?
<SmallPileofGibs> i see it's a problem..
<SmallPileofGibs> xmlGetProp expects you to delete the prop string it returns..
<SmallPileofGibs> for consistency with reference counting, EVERY reference
should be considered
<SmallPileofGibs> any pointer to an object is a reference
<SmallPileofGibs> you should always decref a pointer if it is not NULL and
you're going to discard it
<SmallPileofGibs> you should never ever leave a valid pointer to a referenced
object to go out of scope without decrefing it
<SmallPileofGibs> that's consistent
<SmallPileofGibs> it means that you always have to cleanup your pointers to
referenced objects
<SmallPileofGibs> it means that pointers to the object are always valid
<SmallPileofGibs> nothing else can delete the object while you have a pointer to it
<TTimo> yeah ok




------- You are receiving this mail because: -------
Whoops!  I have no idea!