Re: [boost] Signals doc

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-05-17 09:30:03

On Friday 17 May 2002 09:54 am, Thomas Witt wrote:
> >  and make
> > a notation in the tutorial? Making the notation directly in operator()
> > just "feels wrong".
>
> I think it should be documented in operator() that it is combiner dependent
> whether calling an empty signal is allowed. Maybe adding a footnote
> explaining the return value problem would help.

Would something like this have helped as a note in operator()?

"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)."

> I am used to Qt signal/slot and posix signals. To one of the fundamental
> features of the signals and slots pattern is that the signaller
> does not care about the clients listening. The signaller just makes the
> information available.
>
> So it never came to my mind that calling empty signals might be a problem.
> I now know that it is problem and that there is good reason to implement it
> that way, so I am not criticising the design. I just think there are quite
> a few people with a similar background that might have the same rough start
> when it is not documented at a prominent place.
>
> Just my 2c

I think the design is correct, but maybe the default behavior is wrong. It 
might be easier for users if the default behavior handled having no slots 
more gracefully (e.g., by silently returning a default-constructed value). 
For those (probably few) cases where default construction is not an option, 
the combiner can be changed to do something else.

        Doug