Re: gtkmm 3.0.

[Jonathon Jongsma <jonathon quotidian org>]

On Thu, 2010-03-25 at 18:31 +0100, Murray Cumming wrote:
> On Thu, 2010-03-25 at 14:08 +0000, Chris Vine wrote:
> >   Glib::WeakPtr<Gtk::TreeSelection> s = tree_view.get_selection();
> >   ...
> >   [some code blocks later]
> >   { // scope block for Lock
> >     Glib::WeakPtr<Gtk::TreeSelection>::Lock(s); // take a strong
> > reference
> >     if (s) s->set_mode(Gtk::SELECTION_SINGLE);
> >   }
> >   ... 
> 
> I understand that this might be more correct, but:
> 
> a) This doesn't honestly feel very useful in this case. I'm not likely
> to write code that tries to use the TreeSelection after the TreeView has
> been destroyed. Yes, it can happen, but not intentionally. So I'm not
> likely anyway to bother to check the pointer before dereferencing it.

Right.  With the above design, people could simply ignore the lock and
use the weak pointer without taking a strong reference.  IIRC boost
solves this issue by simply disallowing any use of the pointer via
weak_ptr (they don't provide operator* or operator-> for a weak_ptr).
In other words, you're forced to convert it to a strong reference before
you are able to dereference it.  In that case, the developer is much
more likely to be aware that they need to check the result, e.g.:

WeakPtr<Gtk::TreeSelection> s = tree_view.get_selection();
// not allowed to call e.g. s->set_mode()
if ((RefPtr<T> refptr = s.lock())) {
  refptr->set_mode(...);
}

Of course, the downside is that it's rather annoying to have to do this
for the common case.  Presumably you've called get_selection() in order
to use the selection, so having to perform an extra step in order to
actually use it is not ideal.

For example, the following commonly-used one-liner:
tree_view.get_selection()->set_mode(...);

would become (without validity-checking):
tree_view.get_selection().lock()->set_mode(...);

which isn't much more typing but is significantly less pleasant to look
at.  If you actually checked the pointer before using it, you'd get
something more like the first example above.

-- 
Jonathon Jongsma <jonathon quotidian org>