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 <eriksund@broadpark.no> 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 <typename Iter1Type, typename Iter2Type> boost::zip_iterator<boost::tuple<Iter1Type, Iter2Type> > 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 :)