[Gc] Example for premature reclaim caused by compiler optimization

Martin Wartens martin.wartens at mymail.ch
Fri Sep 9 06:36:14 PDT 2005

Thank you very much for the explanation. I think you already explained this
finalizer thing several times to me, so I should have known by now :-) 
In my example it is safe to use "gc" instead of "gc_cleanup", but I only
know this after inspecting the hidden implementation of std::set. A
precondition is that the global new/delete has been replaced by the
gc-version of it. Using the gc_allocator to instantiate the set is
unnecessary then.
In client code it might be easy to avoid gc_cleanup and finalization, but
in library code it is much harder. The template machinery of C++ makes it
possible to instantiate a class with different types, and some of them may
require finalization. There is no way to find out. The pragma solution
given in your C++-paper could also be problematic in this context. There is
no way for a library class to see which pragmas are defined for the types
it contains. The other way round, the client has no way to see the library

> 1) Make it work as expected, by keeping (or appearing to keep) all
> pointer variables around until the end of their scope.  That includes
> keeping the target of the this pointer reachable while any method on the
> object is executing. 

This was my first thought when I looked at it. Together with a
"remove"-operator that can indicate the end of the lifetime of the pointer
to the compiler. But my guess is that most code wouldn't need it. 

Best regards,
Martin Wartens

mymail - der unschlagbare und kostenlose E-Mail-Dienst der Schweiz!
Der neue Opel Zafira. Sichern Sie sich Ihren Preisvorteil für

More information about the Gc mailing list