Re: [gtkmm] Glib::RefPtr construction

[Michael Johnson <michaelj maine rr com>]

Murray Cumming wrote:
> On Fri, 2003-01-10 at 17:39, Michael Johnson wrote:
> > Having an elegantly simple and intuitive implementation of a smart
> > pointer in the API is a huge win, and that's what I'm trying to
> > accomplish. There's already a smart pointer in the API and it is used
> > extensively. It only makes sense that it should be as generally useful
> > as possible. At the moment, the implementation of RefPtr<> has been
> > polluted by what ought to be internal details of Glib::ObjectBase.
> > Glib::ObjectBase inherits public behaviors from SigC::Object but then
> > modifies those behaviors in an incompatible way. This is bad. If that
> > pollution can be eliminated, then it is worth doing IMHO.
> >   
>
> As for the rest - your idea of not using the GTK+ reference count -
> please just try to code it.
I have a patch ready that implements this. I've tested it with the gtk-demo
as well as the various examples and verified that it works. I made the patch
against the gtkmm2 module in CVS and tested it against the latest changes
(including the menu_elems
change that Murray made today, which is made obsolete by this patch).

I do not believe that I have introduced any backward incompatibility with
any of the public API of gtkmm. Existing gtkmm programs should compile and
run without any changes. However, now there is more latitude in how one uses
RefPtr. It can safely be used to manage references to any class that derives
from SigC::ObjectBase or which implements a compatible interface. The reference
counting behavior of GTK+ is completely hidden by the gtkmm classes, and
all classes that derive from SigC::ObjectBase have reference counting behavior
which is compatible with the base class behaviors.

I'll get it put out on bugzilla sometime today.

..mj