Doug, This is what murray had to say on the GTKmm list (future correspondance, if any, to be on the libsigc++ list), it's a very pleasing response I'm sure you will agree. Perhaps you could qualify you last statement though, that one seems to have murray a little stumped. Cheers! Gaz -----Original Message----- From: Murray Cumming [mailto:murrayc@murrayc.com] Sent: 18 November 2004 09:50 To: Foster, Gareth Cc: 'gtkmm-list@gnome.org'; libsigc-list@gnome.org Subject: Re: [Boost Signals & Slots] Vs [libsigc++] Questions comparing boost::signal to libsigc++ belong on the libsigc++ mailing list. I'm CCing it. boost::signal was developer in cooperation with Karl Nelson, the main original libsigc++ developer. Also, the libsigc++ 2 API was redesigned to be as much like boost::signal as possible, so that gtkmm can easily switch to boost::signal if it becomes an API-stable dependency or it is added to the C++ Standard Library. gtkmm has a long-standing policy of not reimplementing things when we can just reuse them. This part makes no sense to me. It would have to be explained properly before we could comment: " Basically, libsigc++ is a monolithic entity covering single and multiple-target callbacks, slots, and slot binding, Signals tackles only the multiple-target callbacks, relying on other Boost libraries (especially Function and Signals) to do most of the work, so it integrates cleanly with the rest of Boost. " Murray

Hello all,

As you will see in the forward email below, I was chatting to a bloke who works on boost::signal, I wondered how this stacked up against libsigc++, and whether there was any chance it could be used in GTKmm and suchlike. A GTKmm developer did pop up on the boost list and make the valid point that API stability would be a major issue, nevertheless, I thought I'd send this out, and see what people here had to say. As I said on the boost list, I am thinking more ...

...

"hey, what do you think to this lads" than an outright "you should be using Boost heathens!"

I hope such discussion isn't offtopic.

Thanks all!

Gaz

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: 17 November 2004 15:49 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Signals & Slots

On Nov 17, 2004, at 9:20 AM, Foster, Gareth wrote:

...

I was just reading some mention of bugs in boost::signal,

They weren't actually bugs :)

...

is this implementation in competition with libsigc++? i.e. does it aim to do the same job, but under a different license, or is there perhaps some fundamental design difference between the two?

The Signals library aims to be much more flexible than libsigc++ and to have an interface that is more comfortable for Boost. For instance, slots are just function objects with similar signatures (like Boost.Function, because Function is used in Signals), one can combine the results of calling multiple slots into a single return value via an arbitrary function object, and the lifetime of signals & slots is automatically tied to "trackable" objects used in bind expressions to build slots.

Basically, libsigc++ is a monolithic entity covering single and multiple-target callbacks, slots, and slot binding, Signals tackles only the multiple-target callbacks, relying on other Boost libraries (especially Function and Signals) to do most of the work, so it integrates cleanly with the rest of Boost.

Doug

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list

Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com