On Wed, 2010-07-28 at 12:33 +0100, Chris Vine wrote: > On Wed, 28 Jul 2010 12:40:41 +0200 > Murray Cumming <[email protected]> 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++? -- [email protected] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
