Well, I would like to take this opportunity to plug "dataflow iterators" which is part of the serialization library. I wanted the following: a) to be able to compose iterators at to any reasonable depth b) that such a composition occur at compile time. c) to permit a composition to be predefined so it could be used in any subsequent composition. I first considered making functions like the one you propose - make_?_iterator. It didn't seem to me that it was going to satisfy the wish list as stated above. Finally, I found that just by adding to each iterator adaptor a templated constructor of the form // note BaseIterator DOES NOT refer to a base class. It refers to an iterator // whose behavior is going to be modified by my_iterator. template<class BaseIterator> my_iterator(BaseIterator &bi) : ... I could realize all goals stated above. This permited me to build a complex iterator such as convert binary code to base64 by building and testing much simpler constituent iterators and composing them at compile time. I applied it to streams of characters - but I don't think that would be any less useful when applied to something like tuples. Its described in more detail in the documenation for the serialization library. Robert Ramey David Abrahams wrote:

Erik Åldstedt Sund writes:

...

Hi,

just a short question: Why does not the zip_iterator header have the following (or something along the lines of the following) creator function:

template boost::zip_iterator > make_zip_iterator(Iter1Type i, Iter2Type j) { return boost::make_zip_iterator(boost::make_tuple(i, j)); }

Well

a. we didn't think of it

and

b. We'd feel obliged to provide a whole series of overloads for up to N iterators.

...

That would make creating a zip_iterator much simpler.

Patches welcomed, if they include documentation and tests :)

shunsuke wrote:

I tend to think that Boost.Range concept is more cute. That is, 'rng|zipped'. Also, I found Range can be recursive a few weeks ago. If you're interested, see: http://tinyurl.com/2o2mnv

This actually looks very interesting. It begs more study than I can justify at the moment. There is one thing that annoys me about this. That is the usage of the word "oven" presumbly as some sort of play on the word "range". For some reason I find this irksome - it sort of trivializes the work and jars the brain. BTW I have the same complaint about names such as "spirit", "phoenix" and "fusion". They don't mean anything and don't add anything. Robert Ramey