Re: gtkmm 3.0.

[Chris Vine <chris cvine freeserve co uk>]

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);
  }
  ...

This seems to me to be much preferred if you want thread safety,
because when accessing widgets in namespace Gtk, which would be normal
usage, the lock can simply be ignored. It gives maximal efficiency
for the use in question.

Because GObject has all the infrastructure already provided, this would be
trivial to implement.

Chris