On 2007-05-23 13:50:05 GMT, Douglas Gregor wrote:

...

Why are the connect/disconnect methods in boost::signals not const-qualified? You want to abstract away who and how many is listening, don't you? I think it would be natural if these were const methods and emitting a signal required non-const access.

They are non-const because they change the state of the signal.

I realize they need to change the internal state of the signal, I wonder why this internal state is exposed. I would have had the related internal variables mutable. What I'd like to do is equating a non-const reference to the right of emitting a signal. Maybe this is a bad idea? In general, I always have methods like "AddListener" const qualified even though they actually alter internal state.

...

This would allow me to write code like this:

class SomeLogicClass { public: const signal<void()>& GetSomeEventSignal() const; };

In this case, only SomeLogicClass itself can emit signals but anyone can listen to the signal.

Anyone can emit signals this way, since there are both const and non- const function call operators.

I didn't know there was a const emitter. I realize that the emitting method can be const as it probably doesn't affect the state of the signal. It's the same here, either you use constness to model the actual internal state of the signal or you use it to model the right to emit signals.

...

Today I need to add a wrapper method (see below), which preferably is either templated - to accept any functor - or uses boost::function. The first option requires me to have the implementation and include <boost/signal.hpp> in the header file. The second option adds a dependency to boost::function.

Use the slot_type type inside the signal for this.

Perfect, thanks! This lessens the problem.