On Aug 4, 2005, at 5:09 AM, Ames Andreas wrote:

The access violation in simple.cc (when built with NDEBUG) occurs when I try to emit a signal without slots. Documentation seems to state that in this case the return value of the emission is undefined, which seems to imply that the actual call should work (which it should anyway, IMHO). When I compile with _DEBUG defined I get the following assertion thrown at me:

<assertion>

Assertion failed: first != last, file boost/boost/last_value.hpp, line 23

</assertion>

I think the comment in the documentation that you are referring to is: "Calling the function call operator may invoke undefined behavior if no slots are connected to the signal, depending on the combiner used. The default combiner is well-defined for zero slots when the return type is void but is undefined when the return type is any other type (because there is no way to synthesize a return value)." That's trying to say that calling operator() is undefined, except when the result type of the signal is "void". So Signals is correct relative to its documentation, but the documentation itself might be a bit fuzzy.

simple1.cc shows a very basic slot leakage, you will see 9 constructor calls but only 8 destructor calls for the handler. This could be caused by having

pos.impl_->group->second.erase(pos.impl_->slot_);

commented out in named_slot_map.cpp:230.

That embarrassing issue will be fixed in 1.33.0. I can't imagine how it slipped by :(

The half bug I mentioned in the subject is the one which I am least sure about. simple1.cc shows that my callback functor is copied eight times during connect (that obviously implies seven destructor calls). Isn't that a performance issue?

It's actually indicative of a much larger performance issue, but you're right. The performance of Signals in 1.33.0 is improved quite a bit over 1.32.0, but we can still do better, and this is one place where we can improve things. Doug