[Signals & slots]: Why is connect/disconnect not const methods?
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. 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. 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. Both of these thunks or trampoline functions can be avoided if connect/disconnect was consted. // Option 1 class SomeLogicClass { public: template<class Slot> boost::signals::connection ConnectToEventSignal(const Slot& slot) const { ... } }; // Option 2 class SomeLogicClass { public: boost::signals::connection ConnectToEventSignal(const boost::function<void()>& slot) const; }; Best Regards, Johan Torp
On May 23, 2007, at 9:07 AM, Johan Torp 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.
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.
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.
Both of these thunks or trampoline functions can be avoided if connect/disconnect was consted.
I don't see how constness makes any difference, here. Either the signal is public (allowing anyone to connect/disconnect/emit) or it is not. - Doug
participants (2)
-
Douglas Gregor -
Johan Torp