Boost logo

Boost :

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

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
to review.

                    David Abrahams
dave_at_[hidden] *

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