Somebody knows why there are so many explicit destructor calls like :
sp_desktop_dispose (GObject *object) { SPDesktop *dt = SP_DESKTOP (object);
dt->sel_modified_connection.disconnect(); dt->sel_modified_connection.~connection();
dt->sel_changed_connection.disconnect(); dt->sel_changed_connection.~connection();
dt->_set_colorcomponent_signal.~signal();
Why not a simple delete (dt->sel_modified_connection); ?
On Sun, 2004-07-11 at 06:14, Aubanel MONNIER wrote:
Somebody knows why there are so many explicit destructor calls like :
Yes, I'm responsible for most of them. Basically this is deep magic having to do with the relationship between GObject and C++ object initialization.
sp_desktop_dispose (GObject *object) { SPDesktop *dt = SP_DESKTOP (object);
dt->sel_modified_connection.disconnect(); dt->sel_modified_connection.~connection(); dt->sel_changed_connection.disconnect(); dt->sel_changed_connection.~connection(); dt->_set_colorcomponent_signal.~signal();Why not a simple delete (dt->sel_modified_connection); ?
Because SPDesktop::sel_modified_connection is a SigC::Connection, not a SigC::Connection * -- note that the new in sp_desktop_init is a placement new; it initializes existing memory rather than allocating new memory.
These explicit calls are necessary for any members in GObject-derived classes which have non-trivial constructors or destructors.
This is because classes like SPDesktop are allocated as raw memory and initialized by GObject. Consequently, the constructors and destructors of SPDesktop's members (and SPDesktop itself) would never get called unless we do it manually in our overridden _init and _dispose GObject "methods".
[ Sometimes it looks like you can get away without doing so, but that is only because GObject zero-fills memory it allocates, and you're lucky that zero-filled memory looks enough like what the member's class expected. ]
Unfortunately, we can't just call the constructors of the GObject class itself (e.g. SPDesktop) from _init, since that would result in the constructors of base classes being called multiple times
For example, if SPDesktop had a C++ constructor, and SPView had a C++ constructor, sp_view_init() would call SPView::SPView(), and then sp_desktop_init() would call SPDesktop::SPDesktop(), which would also call SPView::SPView(). Not a good situation.
I have modified NRObject to automatically call C++ constructors/destructors, but that was not possible for GObject. NRObject does, however, require that the C++ constructor for every instantiatable class with non-trivial constructors involved be provided as a _cpp_ctor NRObject "method".
-mental
On Sunday 11 July 2004 19:11, MenTaLguY wrote:
On Sun, 2004-07-11 at 06:14, Aubanel MONNIER wrote:
Somebody knows why there are so many explicit destructor calls like :
Yes, I'm responsible for most of them. Basically this is deep magic having to do with the relationship between GObject and C++ object initialization.
sp_desktop_dispose (GObject *object) { SPDesktop *dt = SP_DESKTOP (object);
dt->sel_modified_connection.disconnect(); dt->sel_modified_connection.~connection(); dt->sel_changed_connection.disconnect(); dt->sel_changed_connection.~connection(); dt->_set_colorcomponent_signal.~signal();Why not a simple delete (dt->sel_modified_connection); ?
Because SPDesktop::sel_modified_connection is a SigC::Connection, not a SigC::Connection * -- note that the new in sp_desktop_init is a placement new; it initializes existing memory rather than allocating new memory.
These explicit calls are necessary for any members in GObject-derived classes which have non-trivial constructors or destructors.
This is because classes like SPDesktop are allocated as raw memory and initialized by GObject. Consequently, the constructors and destructors of SPDesktop's members (and SPDesktop itself) would never get called unless we do it manually in our overridden _init and _dispose GObject "methods".
[ Sometimes it looks like you can get away without doing so, but that is only because GObject zero-fills memory it allocates, and you're lucky that zero-filled memory looks enough like what the member's class expected. ]
Unfortunately, we can't just call the constructors of the GObject class itself (e.g. SPDesktop) from _init, since that would result in the constructors of base classes being called multiple times
For example, if SPDesktop had a C++ constructor, and SPView had a C++ constructor, sp_view_init() would call SPView::SPView(), and then sp_desktop_init() would call SPDesktop::SPDesktop(), which would also call SPView::SPView(). Not a good situation.
I have modified NRObject to automatically call C++ constructors/destructors, but that was not possible for GObject. NRObject does, however, require that the C++ constructor for every instantiatable class with non-trivial constructors involved be provided as a _cpp_ctor NRObject "method".
-mental
Not sure I've understoo everything, I never used werid things like placement new before.
So there is a small issue in the patch I've attached to the tracker, because one of the signals uses a marshaller, and I could not find how to explicitly call the dtor
the signal declaration is in libsigc++2 sigc::signal<bool, const SPCSSAttr *>::accumulated<StopOnTrue> _set_style_signal;
But I could not find how to explicitly call the dtor _set_style_signal.~accumulated() didnt work, _set_style_signal.~signal() neither, so I put a simple delete (&_set_style_signal);
of course, this is evil. any idea ?
On Sun, 2004-07-11 at 13:37, Aubanel MONNIER wrote:
So there is a small issue in the patch I've attached to the tracker, because one of the signals uses a marshaller, and I could not find how to explicitly call the dtor
the signal declaration is in libsigc++2 sigc::signal<bool, const SPCSSAttr *>::accumulated<StopOnTrue> _set_style_signal;
But I could not find how to explicitly call the dtor _set_style_signal.~accumulated() didnt work, _set_style_signal.~signal() neither,
Hmm, I would expect _set_style_signal.~accumulated() to work.
What error did you get, and did the compiler indicate what type it thought _set_style_signal had?
so I put a simple delete (&_set_style_signal); of course, this is evil.
Yes ... it also risks corrupting the heap data structures.
-mental
Looks like foo.~accumulated() works, just made a typo. I'll fix the patch ASAP
On Sunday 11 July 2004 19:11, MenTaLguY wrote:
On Sun, 2004-07-11 at 06:14, Aubanel MONNIER wrote:
Somebody knows why there are so many explicit destructor calls like :
Yes, I'm responsible for most of them. Basically this is deep magic having to do with the relationship between GObject and C++ object initialization.
sp_desktop_dispose (GObject *object) { SPDesktop *dt = SP_DESKTOP (object);
dt->sel_modified_connection.disconnect(); dt->sel_modified_connection.~connection(); dt->sel_changed_connection.disconnect(); dt->sel_changed_connection.~connection(); dt->_set_colorcomponent_signal.~signal();Why not a simple delete (dt->sel_modified_connection); ?
Because SPDesktop::sel_modified_connection is a SigC::Connection, not a SigC::Connection * -- note that the new in sp_desktop_init is a placement new; it initializes existing memory rather than allocating new memory.
These explicit calls are necessary for any members in GObject-derived classes which have non-trivial constructors or destructors.
This is because classes like SPDesktop are allocated as raw memory and initialized by GObject. Consequently, the constructors and destructors of SPDesktop's members (and SPDesktop itself) would never get called unless we do it manually in our overridden _init and _dispose GObject "methods".
[ Sometimes it looks like you can get away without doing so, but that is only because GObject zero-fills memory it allocates, and you're lucky that zero-filled memory looks enough like what the member's class expected. ]
Unfortunately, we can't just call the constructors of the GObject class itself (e.g. SPDesktop) from _init, since that would result in the constructors of base classes being called multiple times
For example, if SPDesktop had a C++ constructor, and SPView had a C++ constructor, sp_view_init() would call SPView::SPView(), and then sp_desktop_init() would call SPDesktop::SPDesktop(), which would also call SPView::SPView(). Not a good situation.
I have modified NRObject to automatically call C++ constructors/destructors, but that was not possible for GObject. NRObject does, however, require that the C++ constructor for every instantiatable class with non-trivial constructors involved be provided as a _cpp_ctor NRObject "method".
-mental
participants (2)
-
Aubanel MONNIER -
MenTaLguY