Re: The use of RefPtr

[Chris Vine <chris cvine freeserve co uk>]

On Sun, 08 Mar 2009 22:50:58 +0100
Murray Cumming <murrayc murrayc com> wrote:
> On Sun, 2009-03-08 at 17:33 +0000, Chris Vine wrote:
> > In glib-2/gtk+-2 a lot of the code formerly in GtkObject was moved
> > to GObject.  There is no significant difference in memory management
> > between a pure GObject and a GtkObject, other than the floating
> > reference, which amounts to very little (it is a device to make it
> > easier for containers to take ownership). They could both be wrapped
> > identically in gtkmm, as they are in other bindings such as PyGTK
> > and java-gtk+. They have not been, and that's fine.
> 
> You are welcome to try to create a patch that could be applied for
> gtkmm 3.0. If GTK+ 3.0 really happens as planned (not a plan I like)
> then we will be forced to do an ABI break anyway.

OK.

The changes would be quite extensive so if and when GTK+-3 comes out
lets get a consensus on what approach is best and whether you want to
go through with it. It would be possible to standardise on all
Glib::Objects/Gtk::Objects being managed by intrusive pointer
manipulating their reference counts, as is presently done by gtkmm for
pure GObjects, or to present all Glib::Objects/Gtk::Objects as native
C++ objects with local scope and/or creation by the new expression.  In
either case, this would allow the code to be significantly simplified.

Since glib-2.10, even the floating reference code has been moved from
GtkObject into GObject - now pure GObjects can be given a floating
reference with g_object_force_floating() (the only difference between
GObject and GInitiallyUnowned is that the constructor of
GInitiallyUnowned does that for you). So they could all be dealt with
through floating references if that were helpful to the implementation
(but it probably isn't, depending on how GTK+-3 approaches the issue).

Chris