Re: [boost] signals questions

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-29 00:16:07

Douglas Gregor <gregod_at_[hidden]> writes:

> > The "Signal Invocation" docs say:
> > 
> >   "Effects: invokes the combiner with a slot_call_iterator range
> >   [first, last) (i.e., combiner(first, last)) that iterates over the
> >   results of calling each slot with the given set of parameters a1,
> >   a2, ..., aN."
> >
> > An iterator range doesn't iterate. Maybe you should say "...whose
> > values are the results of calling..." You should also mention that
> > if the iterator stops early, only a subset of the slots will be
> > called. Also you should specify whether it's incrementing or
> > dereferencing of the iterator which causes a slot call. 
> 
> Perhaps this would be better:
> 
> Effects: invokes the combiner with a slot_call_iterator range [first, last) 
> (i.e., combiner(first, last)). Dereferencing an iterator in this range causes 
> a slot call with the given set of parameters (a1, a2, ..., aN), the result of 
> which is returned from the iterator dereference operation.
> 
> Notes: Only the slots associated with iterators that are actually dereferenced 
> will be invoked. Multiple dereferences of the same iterator will not result 
> in multiple slot invocations, because the return value of the slot will be 
> cached.

Better. I think you should say how first and last are formed,
though. It's not just _any_ old slot_call_iterator range, after all.

> > The docs don't make it clear that visit_each is being called without
> > qualification, nor do they say which boost functions call it. Both of
> > those features are important for any point-of-customization that may
> > use Koenig lookup. Also, I realize that with existing compilers, we
> > have to rely on overloading in the user's namespace for this function,
> > but some consideration ought to be given to whether a
> > partially-specializable static member function wrapper wouldn't be the
> > better long-term solution for this case.
> 
> Hmmm, yes. We could use a hybrid approach, with a partially-specializable 
> static member function wrapper whose default falls back to calling visit_each 
> (or some mangled name thereof) unqualified. Is this the best solution within 
> the currently language (and assuming that not everyone can use partial 
> specialization)?

The best solution depends on the situation, of course. However, the
only two viable approaches for customization points are currently
Koenig Lookup and partially-specializable classes with static member
functions.

I don't have a strong opinion about what approach you should choose
for this application; I just want to make sure that customization
points are (in particular uses of Koenig Lookup) are considered and
documented.

> > The last sentence in the "pass slot to disconnect" section is a major
> > run-on. I'm having trouble figuring out what it's supposed to mean.
> 
> Woah! Do I get an award for that sentence? It's astoundingly horrible.

Can you clarify it for me?

> > I'm still wondering, after reading the docs, whether it's OK to send a
> > signal which ultimately destroys the signal itself.
> 
> Yes, that's fine. Signals can be used recursively (signal A calls
> slot B calls signal A) and can be deleted from within a slot they
> call (signal A calls slot B, slot B deletes signal A).

What are the precise semantics of these sorts of interactions? Does
the current call to the signal complete if it is deleted during a
notification? Is there any special interaction with the Combiner? What
if a slot is deleted during a notification? I think the latter is
covered by the whole visit_each thing, but now I've forgotten; I need
to review.

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com