Re: gtkmm 3.0.

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 25 Mar 2010 23:45:24 +0100
Murray Cumming <murrayc murrayc com> wrote:
> On Thu, 2010-03-25 at 14:58 -0500, Jonathon Jongsma wrote:
> > 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(...);
> 
> Sorry, what does that lock() do in this case?
> 
> I don't see how anything gtkmm can do could stop a Treeselection from
> being invalid/ineffective after the TreeView has been deleted.

It is a thread-safety thing.  The idea is to force the taking of an
additional strong reference so the underlying object cannot be destroyed
by thread A while it is being operated on by thread B.  The boost weak
pointer webpage explains it further.

It is of academic interest only in the case of the TreeView because no
one would have two threads controlling the lifetime of the TreeView
object. In the case of GObjects, thread safety is also difficult to
achieve for the reasons I have mentioned in my response to Jonathan.

> Also, I understand the previous examples that check before
> dereferencing, but I'm concerned that any part of my code could
> potentially cause the TreeView to be deleted, so all my code will look
> like this
> 
> if(ptr)
>   ptr->do_something();
> if(ptr)
>   ptr->do_next_thing();
> if(ptr)
>   ptr->do_third_thing();
> 
> And that will be particularly awful when it forces us to declare
> variables apart form their initialization, and make special efforts to
> always clean up properly.

Your point is a good one if it is the case that accessing the methods of
the TreeSelection for a non-existent TreeView does not cause the
program to blow up (and you can live with the copious warnings that
would no doubt be emitted were it not to cause memory faults).  I
suppose the best test of this would be to construct a test case and run
it under valgrind.

Chris