Original Post
Consider the following trivial example: This causes an assert in Boost since there are no registered connections on the signal and because I am trying to use the return value. I understand the reason why the logic should cause some sort of error. My question is why is this an assertion rather than an exception? Signals without connections work fine as long as you do not use the return value (i.e. change FooBar to a void return type and remove the if logic). The offending code is in "last_value.hpp" Now, there is no way to get a "connection count" as far as I can tell on a signal. That means I cannot arbitrarily check for an existing connection before executing such code. I would have to guarantee myself there would always be at least one connection made. If I run into such a case using Signals, am I simply using the library the wrong way in this instance or is this a design oversight on their part? I understand if I were to simply always have a registered connection, I can get around the problem, but I'd like to understand the reasoning for this design. Thanks!
#include <boost/signal.hpp>
bool FooBar() { return true; }
int main(int argc, char * argv[])
{
boost::signal<bool ()> sig;
//sig.connect(FooBar);
if(sig() == true)
{
}
}
template<typename T>
struct last_value {
typedef T result_type;
template<typename InputIterator>
T operator()(InputIterator first, InputIterator last) const
{
assert(first != last); // <-----
T value = *first++;
while (first != last)
value = *first++;
return value;
}
};
