Re: gtkmm 3.0 and libsigc++

[Murray Cumming <murrayc murrayc com>]

On Wed, 2010-07-28 at 12:33 +0100, Chris Vine wrote:
> 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).

So isn't it instead just time to think about using a (copy of)
boost::signal2 instead of libsigc++?

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com