Quoting Ralf Stephan <ralf@...748...>:

The following classes are derived from GC::Managed<> but not from GC::Anchored. Your article suggests that these are misbehaved, too:

Inkscape::Util::ListCell Inkscape::Whiteboard::MessageProcessor Inkscape::Whiteboard::MessageQueue Inkscape::Whiteboard::ProcessorShell Inkscape::Whiteboard::TrackerNode Inkscape::XML::AttributeRecord Inkscape::XML::CompositeNodeObserver Inkscape::XML::ObserverRecord Inkscape::XML::SimpleSession

GC::Anchored is only required to accomodate important references from heap-allocated objects (like a Gtk widget), because the garbage collector does not scan there.

If you can guarantee that objects of a class will always (during their useful lifetime) have references in places the garbage collector can scan:

* on the stack (parameters, return values, local variables)

* heap-allocated objects managed by the GC

* global/static variables

...then, the overhead of GC::Anchored is not necessary.

I do see that the GC::Anchored documentation does not do a sufficient job of explaining the rationale behind GC::Anchored. I'll try to address that.

The problem with removing GC::Anchored from SPDesktop was that the main reference to it was from the desktop widget. The collector cannot see a reference from a GTK widget, so you were risking the premature freeing of the SPDesktop.

A secondary problem is that because of this, the explicit delete could have been called on an already freed object. With any allocator, double deletes risk heap corruption.

Except for classes set up to be allocated with GC::MANUAL (which avoids automatic collection), or specific, very controlled circumstances where the object lifetime is guaranteed, explicit delete is not a good idea for garbage-collector managed objects.

-mental