Re: [boost] libsigc++ inclusion (was Formal review request: Signals library)

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-12-27 08:26:18

From: "Karl Nelson" <kenelson_at_[hidden]>
> This case seems very NIH (from my horribly biased prospective.)
> I have suggested libsigc++ in the past as a boost component, but
> the reasons given for not including it were fairly strong, only
> now it appears those reasons have vanished and a new set of design
> arguments have appeared.  Why was it when I first proposed signal/slot
> implemention boost didn't need such functionality as it was too blended
> with functor, but once function and bind (horrible, horrible name!!)
> which others said were all that are needed, does the signal/slot
> seems appropraite?

I don't really understand your point. Are you saying that

* boost::function<> should die and be replaced by sigc++?
* boost::bind<> should die and be replaced by sigc++?
* The Signals library should not go into boost and sigc++ should be accepted
instead?

> That said, if boost accepts the current set of functor/bind/signal
> combination, and then tries to place it in the stl standard, I
> feel they will be doing a bit of a disservice as some of those
> elements are handled much more gracefully in sigc++.

Could you please elaborate? Which elements are handled more gracefully by
sigc++? Why?

> BTW.  If you are going to drop the slot side of the equation,
> you should really drop the signal name.  Signal/Slot is a unified
> concept and thus if there is no slot class but functors are used,
> don't use the signal name.

A concept doesn't need to have a class with the same name. "Slot" is a
concept. It's possible for a class to meet its requirements without being
named "slot."

--
Peter Dimov
Multi Media Ltd.