Thomas Becker <[EMAIL PROTECTED]> 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost