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

[Christof Petig <christof petig-baender de>]

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?

Also this looks like an easy/small change (apart from refcounting bugs)

Martin Schulze wrote:
> Am 2002.10.08 00:44 schrieb(en) Christof Petig:
>
> > Just a theoretical question (which might solve some memory managaement 
> > problems if possible):
> >
> > Is it possible to write a manage_ref 'function' which would ...
> > - destroy the widget once no RefPtr (or C ref) to it is left
> > - not get the widget destroyed once it's container is destroyed but 
> > unrefed
>
>
> This would be possible but not trivial: We already implement
> our own destroy() callback for Gtk::Container and prevent destruction
> of non-manage()ed widgets there. We could also prevent the destruction
> of manage_ref()ed weigets. I already tested that. The problem is that
> Gtk::Button with a mnemonic starts with a reference count of two after
> construction. This means a child (the mnemonic) holds a strong
> reference to its parent (the Gtk::Button). We would have to add some
> workaraund code for this or Gtk::Buttons with mnemonics would never
> be deleted when manage_ref()ed.
>
> > (unlike manage, IIRC manage does set some gtk+ flag which enables 
> > unconditional destruction)
>
>
> No, manage() does not set some gtk+ flag to enable unconditional
> destruction. gtk+ always does unconditional desctruction. We simply
> prevent the desctruction by reimplementing the container's destroy
> handler removing non-manage()ed widgets before the gtk callback
> can destroy them.
>
> > This would allow code like
> > { Glib::RefPtr<Gtk::Window> w=manage_ref(new Gtk::Window(...));
> >    ...
> >   { Glib::RefPtr<Gtk::Label> l=manage_ref(new Gtk::Label("test"));
> >     w.add(l);
> >   }
> >   ...
> >   // w leavess the scope
> >   // => w gets destroyed, the Label unrefed (and then destroyed)
> > }
> > and if I understand correctly this would solve the destroy vs. unref 
> > problem with widgets. IIRC this would also not force us to use RefPtrs 
> > for any function arguments (function arguments outlive the call).
>
>
> We could not use Glib::RefPtr<> because it doesn't have operator*().
> Otherwise I agree.

This would clearly make one necessary. Murray insisted on not having one 
unless proven to have benefits.

   Christof

PS: rating the ways:
- refcounting: perhaps the new proposed way of handling widgets
[- manage: for backward compatibility with gtk--/early gtkmm2]
[- new/delete: if anybody wants to do it by hand ...]
- scope: for those who prefer it this way