Re: gtkmm 3.0.

[Chris Vine <chris cvine freeserve co uk>]

On Sun, 28 Mar 2010 14:46:17 -0400
Paul Davis <paul linuxaudiosystems com> wrote:
[snip]
> isn't this *precisely* why you use refcounted strong&weak references?
> if ptr was a strong reference to the treeview, it *could not* be
> deleted during ptr's scope.
> 
> otoh, i am sure you know this murray, so i'm probably missing the
> point of your example ...

ptr can't be strong referenced to the tree view using normal syntax.  It
is a pointer to the _tree selection_, which is owned by and specific
to the tree view: and it is because of that ownership and specificity
that the problem arises, which would normally be expressed by using a
weak pointer.

Tree views (in gtkmm as opposed to GTK+) are first class value
objects.  They either exist in scope or on free store, or they don't.
In GTK+ you could obviate the need to keep checking the weak pointer
in murray cumming's example by acquiring a strong reference with
g_object_ref() if the first test of the weak pointer succeeds.  That
won't work in gtkmm (well it would, but you could be left with an
unwrapped C object).

None of this would help with code which tries to access the tree
selection from more than one thread, for the reasons I have previously
set out (but no one with any sense would do that in gtkmm anyway).

I think murray now uses Qt for some projects.  My proposal would do the
same as QWeakPointer when referencing a QObject not managed by
QSharedPointer.  And it is identical to what you would do if
referencing a QWidget: hence putting it in namespace Gtk rather than
Glib.

Chris