On Sun, 28 Mar 2010 14:46:17 -0400 Paul Davis <[email protected]> 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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
