Re: gtkmm 3.0.

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 25 Mar 2010 12:17:01 +0100
Murray Cumming <murrayc murrayc com> 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