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

[Daniel Elstner <daniel elstner gmx net>]

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.

IMHO we shouldn't change the memory management stuff for gtkmm2.  It's
just too late now.  That said, let me outline my proposal of sane memory
management:

1) use Glib::RefPtr<> for all widgets
2) enforce 1)

That's quite harsh I know, but:

>   - manage_ref(new ) and Glib::RefPtr<> [strict refcounting]
This would obviously work.

>   - manage(new ) and add/attach/... [destruction by container, gtk+'s 
> preferred way]
This would also work since the containers do refcounting (we just have
to disable the initial "floating" state, as we already do with
non-managed widgets).  To ease writing and retain backward
compatibility, manage() could look like this:

template <class T> inline
Glib::RefPtr<T> manage(T* obj) { return Glib::RefPtr<T>(obj); }

>   - new and delete [C++'s way]
This is the only thing that won't work anymore.

>   - member/on stack allocation [Scope]
This would work indirectly: if the RefPtr<> goes out of scope and the
last reference is dropped, the object will be deleted.  If you need to
force destruction before the refcount drops to 0, then IMHO something is
borken anyway.

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

As above, I strongly object against yet another way of memory
management.

Cheers,
--Daniel