[boost] Re: Determining interest in combining_iterator

From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-03-27 03:50:05

Thomas Becker <tmbecker1_at_[hidden]> writes:
> > On 26 Mar 2003, Anthony Williams wrote:
> > > It strikes me that if you dereference n iterators,
> > you have n values, and the
> > most natural way to store them is a tuple.
> Once again: The big picture is that we want an
> iterator that parallel-iterates over several sequences
> and upon dereferencing, applies some processing to the
> dereferenced iterator. This processing is specified by
> the user via a fuctional. One of the many, many things
> that such a functional can do is package the arguments
> into a tuple, if that is what's needed. (Although we
> still haven't seen a single real-life request for
> that). Why  on earth would I, in the general case,
> introduce a packaging/unpackaging step in the middle
> between dereferencing the iterators and passing them
> to the functional? Am I missing something?

Basically, I think we have two contradictory scenarios. IIUC, the situations
you have encountered are where you have a set of values in different
containers that needed to be combined into a single value, in which case it
makes sense to pass the values as distinct function arguments to a functor
that does the combining.

OTOH, the situations I am thinking of require that the tuple of containers is
really treated as a container of tuples, complete with the ability to update
the source containers by writing to the tuple obtained by the dereferencing,
but maintaining the value semantics when copied. This is really hard to do in
any other way than by having *it return a "magic tuple", IMHO, though if you
can find a way of doing it as a functor that "just works" without the user
having to know too much, I'll concede the point.
 
> BTW, Anthony: In one of my CUJ columns, I made a big
> fool of myself by gratuitously packaging function
> arguments into a tuple, and I seem to remember that
> you were one of the people who pointed this out to me.
> Looks like we switched sides in this argument... ;-)

Yeah, well, I guess it comes from the use cases I'm thinking of.

Anyway, in the scenarios where a copy would not be required because the
iterators return references, the "magic tuple" would essentially contain
references to the originals (which metamorphose into real copies if you copy
it), so a good optimizer *should* be able to optimize the packing/unpacking
away --- at worst it is a few pointer copies.

I would be quite happy if we had both a combining_iterator and a
tuple_iterator, or if you could find a way of writing a suitable functor as I
stated above.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.