Re: gtkmm 3.0 and libsigc++

[Chris Vine <chris cvine freeserve co uk>]

On Wed, 28 Jul 2010 12:40:41 +0200
Murray Cumming <murrayc murrayc com> wrote:
> On Tue, 2010-07-27 at 16:51 +0200, Krzysztof Kosiński wrote:
> > The easiest way to fix this is to allow sigc++ to depend on Glib
> > when it's present at build time. In addition to being able to use
> > Glib mutexes, we could use the slice allocator. Since the
> > predominant use of libsigc++ is within gtkmm, this would not add an
> > extra dependency in 95% of cases, and in the remaining 5% it could
> > be turned off at build time. Is this OK? 
> 
> I don't think we can consider libsigc++ depending on glib. You should
> see the complaints I get about making libxml++ depend on glib. Can we
> derive something from libsigc++ that we can use in gtkmm instead of
> bare libsigc++ signals?
> 
> And isn't this problem going to be repeated when we eventually start
> using signals from C++0x?
 
A signal/slot interface does not feature in C++0x.  If one were to be
introduced into C++-1x, presumably it would be based on boost::signal2,
which does not have these problems as it has been designed to be
thread safe (and trackability is implemented differently).

Chris