[boost] Re: [range] rationale for transform_range() algorithm?

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-14 12:28:12

"Eric Niebler" <eric_at_[hidden]> wrote in message 
news:4235B296.4050205_at_boost-consulting.com...
| Thorsten Ottosen wrote:
|
| >
| > there is one alternative which might make copy_range less needed too.
| > We could put this into sub_range<T>:
| >
| > operator T() const
| > { return T( begin(), end() ); }
| >
| > So if you really want range2container conversion, you must use a
| > sub_range<string>:
| >
| > str = sub_range<std::string>( find_first(intput, "jello" ) );
| >
|
|
| Eeek, no! Implicit conversions should be avoided.

except when they shouldn't be (like in derived* to base*) :-)

| But thinking of this
| as a range conversion is the right way to go, IMO, except that it should
| be called "range_cast" and it should be explicit.

hm..I dunno, the cast stuff implies some kind of extra work to me.

| 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

if we had

template< class T, class Range >
T copy_to_seq( const Range& r )
{
    T t;
    t.assign(begin(r),end(r));
    return t;
}

support of boost::array<T,size> could be ok.

| 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

The iterator interface suffers
from either being slow or being unsafe, so I don't think that is the way to go 
either.

|. A
| range-based copy algorithm should have a different interface and be part
| of a complete range-based algorithms library.

yes, agreed.

We just need somebody to write those special range algorithms.

-Thorsten