Boost logo

Boost :

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2007-05-23 09:50:05

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

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