On Nov 18, 2004, at 6:49 AM, Foster, Gareth wrote:
-----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. "
Very simple explanation here: my comments were about libsigc++ 1.2. I've glanced briefly at libstdc++ 2 and was pleasantly surprised. I'd like to look into it further, but do not have the time now. I've been saying for a while that the Signals interface is not ready for standardization because we only had the one implementation (in Boost) and that it was not solid enough for standardization. However, with libstdc++ 2 adopting a similar interface, we might be able to converge on a single, solid interface for Signals & Slots within the C++ Standard Library. Library Technical Report 2 is open for submissions, and signals & slots have been on the wish list since the beginning... In any case, a thread titled "Boost Signals & Slots vs. libsigc++" is treading on dangerous territory :) Doug