Re: [gtkmm] Glib::RefPtr construction

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]