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

["Foster, Gareth" <gareth foster siemens com>]

Hello again,

Notice the new, less objectionable thread title, and read below to see
Dougs' latest comments, very interesting stuff.

I do hope people find this little exchange useful, always nice to help.

Cheers!

Gaz


-----Original Message-----
From: boost-users-bounces lists boost org
[mailto:boost-users-bounces lists boost org] On Behalf Of Doug Gregor
Sent: 18 November 2004 15:41
To: boost-users lists boost org
Cc: libsigc-list gnome org; gtkmm-list gnome org
Subject: 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

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