Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at