Thorsten Ottosen wrote:
"Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:cn35c3$g4g$1@sea.gmane.org... | John Torjo wrote:
| > As you probably know, the library is around 1 year old. I've used it | > heavily on some of my projects, and all I can say is that iteration | > capability has helped me much. | > | | If you write all your algorithms to a range interface instead of | iterator | interface, that's a big win when you really want ranges. When you have | to | manually iterate in a loop, it's a loss. Now you have to say: | | template<class in_cont, class out_cont> | algorithm (in_cont const& in, out_cont & out) { | typename boost::range_const_iterator<in_cont>::type i = boost::begin | (in); typename boost::range_iterator<out_cont>::type o = boost::begin | (out); for (; i != boost::end (in); ++i, ++o) ... | | In this case, I'd say it's a net loss.
Sorry, could you elaborate on what the loss is? Using a new iterable range concept we can say
sub_range<const in_cont> r( in ); for( ; r; ++r ) { ... }
I'm confused. We are talking about http://www.torjo.com/rangelib/? I can't find any mention of the above "sub_range" in the zip I grabbed from that site.
If your question is: "should algorithms be implemented in terms of iterators or ranges?", then answer is "iterators". However, it makes sense not to expose the iterator interface once you have added the range layer and the iterator interface might use iterable ranges in its implementation.
Don't know what you mean by "in terms of". I'm thinking that we want algorithms to use ranges for interfaces, like the example I gave of "algorithm" above. Internally, algorithm could use range if it is convenient, like if we could pass to rng::transform, but in general, iterators might be necessary. Is this what you mean?