Architectural question about libgc
The main usage pattern for garbage-collected classes I see is:
Inkscape::XML::Node *foo = doc->createElement("foo"); parent->appendChild(foo); Inkscape::GC::release(foo);
This looks very malloc-free-ish. Why not, instead of deriving from the GC-managed classes, derive from Glib::ObjectBase and then use Glib::RefPtr everywhere? During the migration period, SPObjects etc. can be derived from both Inkscape::GC::Managed etc. and Glib::ObjectBase, and overload the reference() and unreference() virtual methods to call Inkscape::GC::anchor() and Inkscape::GC::release().
However, I don't know the codebase too well, so probably there's some more fundamental reason to using libgc other than managing objects which have multiple references - please enlighten me :).
Regards, Krzysztof Kosiński
Krysztof,
Hi,
I'm not the wizard on this, but I think I can give a fairly good answer (Mental, please correct my obvious errors here :-) !
The reason is, that not everything in Inkscape is C++ yet, and we need to use the lower-level functions of Boehm rather than relying on C++ stuff. A lot of Inkscape things are still C wrapped in C++. Some day that will be different, but it still hasn't happened yet.
bob (ishmal)
Krzysztof Kosiński wrote:
The main usage pattern for garbage-collected classes I see is:
Inkscape::XML::Node *foo = doc->createElement("foo"); parent->appendChild(foo); Inkscape::GC::release(foo);
This looks very malloc-free-ish. Why not, instead of deriving from the GC-managed classes, derive from Glib::ObjectBase and then use Glib::RefPtr everywhere? During the migration period, SPObjects etc. can be derived from both Inkscape::GC::Managed etc. and Glib::ObjectBase, and overload the reference() and unreference() virtual methods to call Inkscape::GC::anchor() and Inkscape::GC::release().
However, I don't know the codebase too well, so probably there's some more fundamental reason to using libgc other than managing objects which have multiple references - please enlighten me :).
Regards, Krzysztof Kosiński
Bob Jamison-2 wrote:
Krysztof,
Hi,
I'm not the wizard on this, but I think I can give a fairly good answer (Mental, please correct my obvious errors here :-) !
The reason is, that not everything in Inkscape is C++ yet, and we need to use the lower-level functions of Boehm rather than relying on C++ stuff. A lot of Inkscape things are still C wrapped in C++. Some day that will be different, but it still hasn't happened yet.
bob (ishmal)
There must be a more important reason, probably that Sodipodi or Gill used libgc from the start, and it was carried over into Inkscape. I don't know how having C things wrapped in classes can be relevant to using garbage collection instead of smart pointers - can you explain in more detail?
Regards, Krzysztof Kosiński
participants (2)
-
Bob Jamison -
Krzysztof Kosiński