Re: gtkmm 3.0.

[Paul Davis <paul linuxaudiosystems com>]

On Thu, Mar 25, 2010 at 10:08 AM, Chris Vine
<chris cvine freeserve co uk> wrote:
> On Thu, 25 Mar 2010 13:13:32 +0000
> Chris Vine <chris cvine freeserve co uk> wrote:
>> 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.
>
> Actually, if one wanted thread safety for future proofing, since
> GObjects maintain their own reference count we don't have to ape the
> way weak pointers do it with shared pointers, and we can have a locking
> class which increments the reference count in its constructor and
> decrements it in its destructor, for eg:
>
>  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 prefer the boost syntax for this:

    boost::weak_ptr<Foo> weak_foo = ....;
    ...
    [ // scope begins for use of referenced object ...
           boost::shared_ptr<Foo> shared_foo = weak_foo.lock ();
           if (shared_foo) {
                ... use shared_foo to access object ....
           }
    ] // scope ends

although its clearly semantically equivalent. in your example, you've
changed the nature of s from a weak reference to a strong reference.
if it wasn't scoped, that could cause some odd side effects. either s
is or is not a weak reference, preferably.

as i've mentioned to daniel on IRC, it would make our life in ardour
MUCH easier if all gtkmm objects were reference counted with both weak
and strong references available. we have a very nasty and hard to deal
with situation right now where we schedule a callback on a GUI object
from a non-GUI thread, and by the time the callback is executed, the
GUI object has been deleted.

--p