Boost logo

Boost :

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" . 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)

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at