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

[Doug Gregor <dgregor cs indiana edu>]

On Nov 18, 2004, at 1:10 PM, Murray Cumming wrote:

> > Very simple explanation here: my comments were about libsigc++ 1.2.
>
> It would be best for us to ignore them then. The differences are quite 
> large.

Yes, please ignore them.

> > I've glanced briefly at libstdc++ 2
>
> For the record, Doug almost certainly means "libsigc++" instead of
> "libstdc++".

Correct.

> > 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 :)
>
> I doubt that Boost Signals and libsigc++ 2 are significantly different.

My cursory review of the libSIGc++ 2 reference documentation seems to 
indicate that the interfaces are similar.

> A comparison should probably start by looking at the application code
> needed to
> 1. Create a signal
> 2. Connect a slot (callback function) to a signal.
>   2.2 For a member method.
>   2.3 For a non-member or static function.
> 3. Disconnect a slot.
> 4. Bind an extra parameter, so that e.g. a slot with 4 parameters can 
> be
> used with a signal with 3 parameters. I don't personally find the more
> complex adaptors interesting.

I'm not in a position to do this at the moment, although possibly in 
the future. It would be *wonderful* if someone went off and studied 
both libraries in-depth to make this comparison, especially if that 
person was not intimately familiar with either library beforehand.

> Please do try to warn us if Boost Signals seems near to being 
> approved. We
> would like to try porting gtkmm to it then.

There is no current effort to write a proposal to bring the 
Boost.Signals interface to the C++ committee (that I know of). If this 
does happen, it will be _after_ we have a detailed comparison of both 
libraries and, of course, I will announce it on both the libSIGc++ and 
Boost mailing lists.

	Doug