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

[Christof Petig <christof petig-baender de>]

Daniel Elstner wrote:
> Am Die, 2002-10-08 um 12.09 schrieb Christof Petig:
> > Doesn't this solve the problem while being backward compatible.
> > The name manage_ref is debatable. Perhaps refcount() would be better?

Actually I prefer refcount() for clarity, now. It's syntax is like manage().

> First, I think the last thing we should do at this point is introducing
> yet another memory management option.

You are obviously right. But this would mean to _drop_ source code 
compatibility once a decent reference counting solution is designed.

AFAICT this solution gives us a working refcount solution _now_. And 
makes use of it optional.

> 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.

No, it would explicitely allow the widget to get refcounted. This way we 
would get a working refcounting solution while maintaining 
compatibility. Refcounting as an optional add-on ;-(

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

IMHO this is absolutely to avoid, even in future revisions. 95% of 
existing code works this way (at least of the code I know about).

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

I think that having designed a decent refcounting solution should not 
render working code broken.

   Christof

PS: To sum up the benefits of my proposal:
- source compatibilty
- working widget RefPtr with about 20-50 additional lines of code (yet 
to be proven)
Disadvantages:
- doesn't force the programmer to use refcounting
- refcounting isn't the default

Outline:
- needs another flag in Gtk::Object to indicate refcounting management 
(which is default for gdk/glib/sigc objects IIRC)
- combine destroy mechanisms to resemble both managed (automatic 
deletion, but only on refcount=0) and unmanaged (does not get destroyed 
with its container) widgets.

Problems:
- if existing code does not permit unmanaged widgets to fully outlive 
their container, a refcounted would do neither (I heard rumors about 
removal on container destruction to prevent destruction of the unmanaged 
widget).