On Thu, 25 Mar 2010 12:17:01 +0100 Murray Cumming <[email protected]> wrote: > What would some application code look like if you fixed this in the > gtkmm API?
A minimal interface would be something like: Gtk::WeakPtr<Gtk::TreeSelection> s = tree_view.get_selection(); ... [some code blocks later] if (s) s->set_mode(Gtk::SELECTION_SINGLE); ... [some more code blocks later] Gtk::TreeModel::iterator iter; if (s) iter = s->get_selected(model); In this example Gtk::WeakPtr has an operator bool() method to determine whether it is referencing a live GObject. Another common name for the same method in weak pointers is 'expired()'. We could provide both as synonyms. You might want an attempt to call operator->() on an expired WeakPtr throw an exception. The 'if (s) ...' approach is not thread safe and because of that this example puts WeakPtr in namespace Gtk rather than namespace Glib. This is because another thread could release the last remaining strong reference between the calling of WeakPtr::operator bool() and operator->() completing. To make it thread-safe WeakPtr would need to be type convertible to Glib::RefPtr so a strong reference is held in that part of the code, and require Glib::RefPtr::operator->() and Glib::RefPtr::operator bool() to be used (ie have no Gtk::WeakPtr::operator->() method), but that seems to me to be irrelevant to gtkmm, which doesn't hold itself out to be thread safe. But WeakPtr could be made thread safe in the way I have mentioned, because from from glib-2.8 the GObject reference count is thread safe: but I doubt it is worth it (and doing so would make the interface more cumbersome). However, if it were made thread safe, its natural home would be namespace Glib. Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
