> 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.
In general we avoid guessing such (undocumented) internal lifetime details, and just do the same thing with all GObjects. C coders do whatever works, with lots of errors along the way. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
