Pavol Droba wrote:
transform_range is not so crucial, but the copy_range is very important. Without it you cannot easily convert iterator_range to a string for instance. You need to go through iterator-constructor.
So instead of
str=copy_range<std::string>(aRange);
You need to write str=std::string(aRange.begin(), aRange.end());
The second one is not as nice, but what is more important, it disallows you to pass a range by value in a chain. In other words, you cannot write
str=copy_range<std::string>(find_first(input,"helo"));
I agree this functionality is useful, but this is a rather unfortunate interface choice, in my opinion. For instance, what if I want to copy to an array: int rg[3] = copy_range<int[3]>(aRange); // oops, can't return array And what if I want to write into pre-allocated space? What if I want to copy to a non-stl sequence, or one doesn't have a constructor that takes 2 iterators as parameters? This is not general or extensible. All these problems are handled nicely by the std::copy algorithm, which takes an output iterator as a parameter. A general, extensible range-based algorithm library should take output /ranges/ as parameters, or even just an output iterator, but this is all beside the point. A range-based copy algorithm should have a different interface and be part of a complete range-based algorithms library. And that if you *still* want a function that creates a new sequence from a range of a different type, then copy_range() is the wrong name. "copy" implies that you can specify space for the destination. What you have looks more like lexical_cast to me. Maybe this should be range_cast: str = range_cast<std::string>(aRange); -- Eric Niebler Boost Consulting www.boost-consulting.com