RE: [boost] Re: Formal Review: Signals

From: Gary Powell (powellg_at_[hidden])
Date: 2002-02-26 18:35:26

>>----------------------------------------
>   In case there is some major overhead with calling operator*();
> Or am I missing something. Do the "iterators" have state, and therefore
> depend on the correct number of calls to operator*()? This is not at
> all clear from the code. (The tutorial hints at this.)

Just to make sure we're on the same page: the first time operator* is
invoked
on one of these iterators, the slot is called with the set of arguments
given
to the signal and the return value is cached. Any time after the initial
dereference and prior to an increment, operator* returns the cached value.
If
the iterator is never dereferenced, the slot is never called.
<<------------------------------------------------------------
Ok I think I got this.

>>------------------------------------------------------
> Ok, I just read the doc's and I still think its a misuse of operator*().
> IMO it would be more clear use of an iterator if
>
>    (*iter++)();
> was the call that generated the side effect.

What is your reaction to transform_iterator from the iterator adaptors
library? It also uses operator* to invoke a function.
<<------------------------------------------------------
I don't mind the transform_iterator calling operator*() for the same
reason that you state below. I always thought of a transform iterator
as "stateless" and that it could be considered a value. Hence that
operator*() called the underlying transform function _each_ time, and
did not cache the result. (But I suppose that could be an implementation
detail.)

>>-----------------------------------------------------
In any case, here's my
justification:

From the point of view of a combiner, the sequence of slot calls is merely a
sequence of values. We already have a concept that describes a sequence of
values: an input iterator sequence. By reusing that concept, we are
automatically able to reuse any operation defined on input iterator
sequences, and the STL is full of those.
<<------------------------------------------------------
But is this really the case? That the signal will/should only be sent once?
That the result can be considered a "value", and not that the act of
calling the function is the effect we are looking for?

I may be really confused here. But I'd like to become enlightened. Does
anyone
who has used the Signal/Slot concept in production code care to chime in
on this?

(Also note: this is an implementation detail AFAIK, and maybe I'm
complaining
about things that are really better left up the author of the library. It's
just that at first look at the code, it's not obvious what *iter is doing.
And
as a maintainer of other people's code I prefer to have things like this
stand
out a bit more so I don't mess it up, rewriting things that shouldn't be
touched)

>> ==========================
New Statement:
Let me also chime in that I think that order of signaling
can be very important to some applications. And that it would
be good for the user of the library to be able to specify, FIFO, or
LIFO for signal handlers.

>>-----------------------
Thanks for the detailed comments.
<<-----------------------
You're welcome. Thanks for all the great work!

  Yours,
 -gary-