From: Eric Niebler (eric_at_[hidden])
Date: 2005-03-14 10:46:17
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