Re: [gtkmm] "manage" and Glib::RefPtr

[MHL Schulze t-online de (Martin Schulze)]

Am 2002.10.10 15:10 schrieb(en) Daniel Elstner:
> Am Die, 2002-10-08 um 12.09 schrieb Christof Petig:
> > Hi Daniel,
> >
> > what do you think about this fourth (or whatever) variant of memory
> > management which states at widget creation that the widget is to be
> > strictly refcounted:
> >
> >   - manage_ref(new ) and Glib::RefPtr<> [strict refcounting]
> >   - manage(new ) and add/attach/... [destruction by container, gtk+'s
> > preferred way]
> >   - new and delete [C++'s way]
> >   - member/on stack allocation [Scope]
> >
> > Doesn't this solve the problem while being backward compatible.
> > The name manage_ref is debatable. Perhaps refcount() would be better?
>
> First, I think the last thing we should do at this point is introducing
> yet another memory management option.
>
> What would manage_ref() do?  I think it would be the same as writing
> Glib::RefPtr<Foo>(new Foo()) directly (though that won't work with
> special cased widgets like GtkWindow or GtkInvisible).  Therefore we
> don't really need a function to do that.

This is only a technical note about the current gtkmm2 code to avoid
misunderstandings:
Using Glib::RefPtr<Foo>(new Foo()) doesn't work if Foo inherits
Gtk::Object: The c++ wrapper Foo will never be deleted because the
line "delete this" in Gtk::Object::destroy_notify_() is not executed
unless "referenced_" is false, i.e. unless the object is manage()ed.

By the way, I'm dying to hear more about what else has been discussed
and decided in Berlin :-) I do hope you all had a nice time?

Regards,

  Martin