[boost] Boost Signal Bug

From: Neal Coombes (nealc_at_[hidden])
Date: 2004-06-30 11:14:18

I've experienced the same problem discussed on June 3rd titled "Bug, 
signals, use of default Combiner" 
http://thread.gmane.org/gmane.comp.lib.boost.devel/103903 .  I would 
have just replied except its a little old, thus a new thread.

Doug Gregor wrote:
 > We intentionally did not return a default-constructed value because
 > the returned type might not have a default constructor. Granted, this
 > case might be sufficiently rare to justify using your version of
 > last_value.

I would like to say a few things about this and offer an alternative 
solution.  First, I think not returning a default constructed value is 
the correct approach with the last_value combiner for the reasons you've 
mentioned.  I don't think the bug is with the last_value combiner, but 
with the fact that the last_value combiner is the default combiner (ok 
an exception rather than an assert would probably be better).

However, I would venture to claim that a signal being called without any 
slots is not a rare case.  In fact I'd guess that might be the most 
likely case.  Certainly, as a library writer, I cannot assume that all 
the signals I provide to my users are going to be used in every application.

My suggestion is to provide a default combiner that does the bare 
minimum, just call the slots:

namespace boost {
   struct default_combiner {
     typedef void result_type;

     template<typename InputIterator>
     result_type operator()(InputIterator first,
                            InputIterator last) const
     {
       while (first != last)
         *first++;
     }
   };
}

I believe this would solve the problem without restricting use of 
default signals to objects with default constructors, or to signals with 
at least one slot connected.