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
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
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
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
> > 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
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk