Re: [boost] Signals (& Slots) library updated

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-11-21 21:07:35

Doug,

Nice explanation, rationale, and comparison to libsigc++!

Please add this to your docs.  The C++ committee is very interested in both 
rationale for design decisions, and comparisons to other libraries.  So 
even if it is just a copy of your raw message below, please to add it.

I think I'm going to start encouraging Boost developers to add a (possibly 
empty) FAQ to docs right from the word go.  That way there is a place to 
put answers to questions as they come up.

Cheers,

--Beman

At 06:50 PM 11/21/2001, Douglas Gregor wrote:
 >On Wednesday 21 November 2001 04:48 am, you wrote:
 >> I'm sorry for possible off-topic, but could you please comment how your
 >> work is related to libsigc++?
 >
 >I can give you a comparison 'to the best of my knowledge.' I've looked at 

 >the
 >documentation and implementation of libsigc++ before, but have not used 
it
 >extensively.
 >
 >The libraries are quite similar on the surface - the connection and 
signal
 >classes from each have nearly identical interfaces; the SigC::Object 
class
 >is
 >quite similar to the "bindable" class from Signals in that a user type
 >derives from one of these classes to enable automatic connection lifetime 

 >management (which both libraries support).
 >
 >I'll try to describe the differences in greater detail:
 >
 >libsigc++ Marshallers vs. Signals Combiners
 >-----------------------------------------------------
 >Both of these entities perform the same function: when a signal calls
 >multiple slots, there must be some way to take the return values of many
 >slots and make it into a return value for the signal itself.
 >
 >The libsigc++ Marshaller interface looks like this:
 > struct  SomeMarshal
 >    {
 >       // both typedefs must be defined.
 >       typedef Type1 InType;   // type returned by a slot
 >       typedef Type2 OutType; // type returned by the signal
 >
 >       // Return final return code.
 >       OutType value();
 >
 >       // Return value if marshaller does not get built
 >       static OutType default_value();
 >
 >       // Captures return codes and returns TRUE to stop emittion.
 >       bool marshal(const InType&);
 >
 >       SomeMarshal();
 >   };
 >
 >When a libsigc++ signal invokes its slots, it will essentially do this:
 >  Marshaller marshaller;
 >  while (slot = next_slot() && marshaller.marshal(slot(...)));
 >  return marshaller.value();
 >
 >The Signals Combiner interface looks like this:
 >struct Combiner {
 >  typedef T result_type;
 >  template<typename InputIterator>
 >  T operator()(InputIterator first, InputIterator last) const;
 >};
 >
 >When a Signals signal invokes its slots, it will do this:
 >Combiner combiner;
 >return combiner(first, last);
 >
 >There is no difference in the power or flexibility afforded by either
 >option.
 >However, I'll claim that the approach taken by the Signals library is 
more
 >natural within the context of C++: the act of calling the slots is merely 

 >the
 >iteration through the input iterator sequence the combiner is given, and 
the
 >
 >combiner itself is just a function object taking an input iterator range. 

 >Often, it's much easier to use an interface where you "pull" the data as 
you
 >
 >want it: if you don't pull data from a slot, that slot won't be called, 
so
 >the equivalent of a libsigc++ marshaller returning "TRUE" from marshal() 
is
 >a
 >return statement in a Signals combiner.
 >
 >It is, of course, a matter of preference, but I believe that a function
 >object taking an input iterator sequence and returning a value is more 
"in
 >the spirit of C++" than defining a special interface for this same
 >operation.
 >
 >Argument Binding
 >---------------------
 >Both libraries "allow" argument binding, and arguments bound in creating
 >slots can be tracked so that when they die, connections involving them 
are
 >removed. The difference between libsigc++ and Signals is mostly
 >philosophical: libsigc++ includes limited capability for binding 
arguments,
 >
 >and can track objects bound in the manner. Signals, on the other hand, 
does
 >
 >not do any argument binding. Instead, another binder library (e.g.,
 >Boost.Bind or Lambda) will perform argument binding and there is a bound
 >argument discovery interface used by Signals to find those arguments.
 >
 >This keeps Signals decoupled from binding, so as new binding libraries
 >become
 >available Signals can adapt to them without any internal changes. 
libsigc++
 >
 >doesn't currently have this ability.
 >
 >What's a Slot?
 >-----------------
 >Signals has a much looser definition of a slot than libsigc++ does.
 >libsigc++
 >is relatively strict regarding what a slot is -- return and argument 
types
 >should match exactly with the signal, and if there is a difference one 
must
 >
 >manually build an adaptor to the appropriate type.
 >
 >The Signals definition of a slot is the same as that of a target for
 >Boost.Function -- anything such that parameters of the type taken by the
 >signal can be passed to the slot, and the return value of the slot 
converted
 >
 >to the type expected by the signal. Thus all adaption is done internally
 >without user intervention.
 >
 >I'll claim that the looser definition is more appropriate for a few
 >reasons:
 >  - It's silly to manually adapt because the signal takes an std::string 
and
 >
 >the slot takes a const std::string&.
 >  - Manual adaptations clutter the code (other side of the coin: they 
make
 >conversions explicit -- my side of the coin: they make trivial 
conversions
 >explicit, too)
 >  - Generic libraries define interfaces in terms of expressions, not 
types.
 >
 >So saying that we need a function object that takes two ints and returns 
an
 >
 >float is uncommon: instead we say that we need the expression f(a, b) to 
be
 >
 >convertible to a float when a, b are integers. Signals follows this 
generic
 >
 >programming view more closely.
 >
 >I hope such a comparison was useful, and if there are any other details 
of
 >libsigc++ for which information about the Signals equivalent could be
 >helpful, please do ask.
 >
 >	Doug
 >
 >Info: http://www.boost.org  Unsubscribe:
 ><mailto:boost-unsubscribe_at_[hidden]>
 >
 >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/