Foster, Gareth wrote:
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
Indeed more than I would have expected from Murray. ;) But then again, I didn't know that sigc++-2.0 was designed to be "interface-compatible" to boost. A very good response then :) Hagen.