[sigc] Re: [Boost-users] Signals & Slots



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]