On Thu, 2006-07-06 at 21:55 +0100, Chris Vine wrote: > On Thursday 06 July 2006 21:44, Chris Vine wrote: > > > > Glib::RefPtr is designed to reference objects derived from GObject (sorry, > > I can't remember their glibmm class designation, probably Glib::Object) but > > not from GtkObject (Gtk::Object). Classes derived from Gtk::Object are > > owned by the container in which they are placed, if you provide they are to > > be managed (as you did). If you assign them to a Glib::RefPtr you will > > need to increment the reference count when doing so in order to pass > > ownership to the Glib::RefPtr smart pointer. If you don't have them as > > managed objects, you don't need to increment the reference count (but you > > may have to call gtk_object_sink() on them to eliminate the floating > > reference - I am not sure whether you need to do this in gtkmm because I > > either use the raw C objects or, with gtkmm, have them managed by the > > container). > > Actually I am not sure if I am right about the last sentence - it is true > with > GTK+ (with C objects) but I am not sure about gtkmm - you probably need to > call delete on the gtkmm object at some stage if it is not managed by the > container, since bringing the reference count to 0 will cause the underlying > C object to be destroyed but not the C++ superstructure on top. The best > rule is never to use Glib::RefPtr with objects derived from Gtk::Object.
Your conclusion is correct. http://www.gtkmm.org/gtkmm2/docs/tutorial/html/ch18.html -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
