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)); } That would make creating a zip_iterator much simpler. Instead of writing the following: std::set<double> s; std::vector<int> v; // populate s and v.... std::for_each(boost::make_zip_iterator(boost::make_tuple(s.begin(), v.begin())), boost::make_zip_iterator(boost::make_tuple(s.end(), v.end())), my_functor_that_does_something_useful()); you could write the following: std::set<double> aSet; std::vector<int> aVector; // populate aSet and aVector.... std::for_each(boost::make_zip_iterator(aSet.begin(), aVector.begin()), boost::make_zip_iterator(aSet.end(), aVector.end())), my_functor_that_does_something_useful()); Regards, Erik Åldstedt Sund
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 :) -- Dave Abrahams Boost Consulting www.boost-consulting.com
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 :)
Robert Ramey wrote:
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.
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 is a hopeless war on functional languages. :-) Regards, -- Shunsuke Sogame
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
On 2/17/07, Robert Ramey <ramey@rrsd.com> wrote:
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.
Agreed. (in general - I don't mean to pick on 'oven' in particular). As much as I actually like the homour and the extra level of thinking that it forces onto my brain, it does make things confusing for the non-english. I don't mind fusion so much though - it does have some meaning (as the fusion of compile time and runtime). And it so generic that it is hard to name well. - Tony
participants (5)
-
David Abrahams -
Erik Åldstedt Sund -
Gottlob Frege -
Robert Ramey -
shunsuke