Boost logo

Boost Users :

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-11-18 14:09:36


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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net