On Sunday 10 April 2005 12:11, Murray Cumming wrote: > > gtkmm uses > > Glib::RefPtr for things derived from GObject even where GTK+ does not > > expect > > you to manage the lifetime of the unwrapped object. Taking the example > > of gtk_tree_view_get_selection(), in the gtkmm equivalent > > (Gtk::TreeView::get_selection()), the Gtk::TreeSelection object is > > delivered > > to you via a Glib::RefPtr and gtkmm adds an additional reference count > > (which > > GTK+ does not) before doing so for the purpose. (Whether that is a good > > thing is debatable, as the TreeSelection object has no meaning if the > > TreeView has been destroyed, so it is an ineffective ghost if the > > TreeView is > > destroyed before the object holding the Glib::RefPtr finally disposes of > > it, > > but it has the merit of consistency.) > > It would be an invalid (as in, things crash if you use it) object either > way. RefPtr manages the object properly whether the programmer wants to or > not.
Yes the object would be invalid in either case. Equally, the object would be just as well managed if a raw pointer were passed and the reference count were not incremented - in other words, if the GTK+ approach were adopted. I am not saying that the gtkmm approach is wrong, but another policy which could be adopted is that accessors will pass on objects by reference counted pointer only if the object is valid whilst the reference count is greater than 0 - that is, where the claim of shared ownership implicit in a reference counted pointer is modelled in practice. Chris -- Summer is y-cumen in, lhude sing, cuccu! Groweth sed and bloweth med, springeth the wude nu. _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
