I just committed a conversion of the whole UI::View::View hierarchy over to the collector -- you can't do leaf classes individually and have it work right. Has to be everything in the hierarchy.
Not 100% sure I got the code straight because it was a very quick job, but I think so. I'll keep testing.
Important thing for everyone to realize: just like refcounted GObjects and so forth, GC::Anchored objects start with a "refcount" of one. No need to refcount them a second time after you create them. I've made this even more explicit in the CG::Anchored documentation which I would encourage everyone to read...
-mental
On Tue, Sep 27, 2005 at 11:24:01PM -0400, MenTaLguY wrote:
I just committed a conversion of the whole UI::View::View hierarchy over to the collector -- you can't do leaf classes individually and have it work right. Has to be everything in the hierarchy.
Not 100% sure I got the code straight because it was a very quick job, but I think so. I'll keep testing.
Important thing for everyone to realize: just like refcounted GObjects and so forth, GC::Anchored objects start with a "refcount" of one. No need to refcount them a second time after you create them. I've made this even more explicit in the CG::Anchored documentation which I would encourage everyone to read...
Where is that documentation?
Bryce
On Tue, 2005-09-27 at 21:02 -0700, Bryce Harrington wrote:
On Tue, Sep 27, 2005 at 11:24:01PM -0400, MenTaLguY wrote:
I've made this even more explicit in the CG::Anchored documentation which I would encourage everyone to read...
Where is that documentation?
For GC::Anchored? See gc-anchored.h, of course.
The GC::Finalized documentation in gc-finalized.h is probably also worth reading.
gc-core.h and gc-managed.h could stand a few more comments, but they are mostly trivial wrapper classes/functions, for which reading the documentation for the corresponding libgc APIs should largely suffice.
-mental
Important thing for everyone to realize: just like refcounted GObjects and so forth, GC::Anchored objects start with a "refcount" of one. No need to refcount them a second time after you create them. I've made this even more explicit in the CG::Anchored documentation which I would encourage everyone to read...
Thanks for documenting. Please include in your documentation how to handle errors like:
application/editor.cpp: In constructor ‘Inkscape::NSApplication::Editor::Editor(gint, char**, bool)’: ./gc-managed.h:54: error: ‘static void* Inkscape::GC::Managed<default_scan, default_collect>::operator new(size_t, Inkscape::GC::ScanPolicy, Inkscape::GC::CollectionPolicy) [with Inkscape::GC::ScanPolicy default_scan = SCANNED, Inkscape::GC::CollectionPolicy default_collect = AUTO]’ is inaccessible application/editor.cpp:47: error: within this context application/editor.cpp: In destructor ‘virtual Inkscape::NSApplication::Editor::~Editor()’: ./gc-managed.h:67: error: ‘static void Inkscape::GC::Managed<default_scan, default_collect>::operator delete(void*) [with Inkscape::GC::ScanPolicy default_scan = SCANNED, Inkscape::GC::CollectionPolicy default_collect = AUTO]’ is inaccessible application/editor.cpp:78: error: within this context make[2]: *** [application/editor.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
(which is very cryptic)
I have looked in gc-managed.h but didn't find a thing about it.
ralf
Quoting Ralf Stephan <ralf@...748...>:
make[2]: *** [application/editor.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
(which is very cryptic)
Found it. You should have derived from public View not View.
Ah, good catch actually. That specific cause hadn't occurred to me. Add that to the earlier list of stuff that can cause such an error.
-mental
Quoting Ralf Stephan <ralf@...748...>:
(which is very cryptic)
Sadly that's par for the course with C++ errors.
I have looked in gc-managed.h but didn't find a thing about it.
The error is a C++ issue rather than anything specific to the Inkscape::GC APIs. One base class (Gtk::Window in this case) is hiding the custom new and delete operators introduced by another base class (in this case GC::Managed).
In general when you see a message like:
somefile.cpp: In [function a]: someotherfile.h: error: [member function] is inaccessible somefile.cpp:[line number]: error: within this context
It means the code (at somefile.cpp:[line number]) is trying to access a protected or private member function as if it were public.
If the member function is in fact declared as public, then it is likely being hidden by an interaction between different base classes.
-mental
participants (4)
-
unknown＠example.com -
Bryce Harrington -
MenTaLguY -
Ralf Stephan