Re: When and when not to use Glib::RefPtr?

> 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

Murray Cumming
murrayc murrayc com

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