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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-14 15:34:19

"Eric Niebler" <eric_at_[hidden]> wrote in message 
news:4235E56D.2090109_at_boost-consulting.com...
| Thorsten Ottosen wrote:
| > "Eric Niebler" <eric_at_[hidden]> wrote in message
|
| >
| > | 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.
| >
|
| Could you explain this a bit?

well, I expect a "cast" to be more than a copy algorithm.

| copy(from, to). That's the idiomatic way of writing a copy function.
| What you have above is a conversion function, and typically we call
| those things casts.

Ok, I just read it a copy-like algorithm.

|
| >
| > | 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.
|
|
| You're saying that either an output iterator is range-checked and it's
| slow, or it's not an it's unsafe. How is an output range any different?

we know its size; we don't know how far an iterator is valid.

take something as simple as

copy( begin, end, std::back_inserter( a_vector ) );

this is safe, but super dum since we don't take advantage of
the size of the range [begin, end) might be know for forward iterators.
OTOH, If I pass copy() a naked iterator, it is fast, but not range checked.

| It's a sincere question -- I really don't know if output ranges have
| anything to offer above output iterators.

There is no official Output Range concept, but you can have
a Writeable Range to be overwritten.

| >
| > |. 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.
| >
|
| Have you missed it? I've got one in the sandbox, but it needs attention.

no, no, I know you have started from where I left off.
And that is goooood :-)

But I thought you meant more range algorithms; for example,
std::copy is what I would call an iterator algorithm; an range
algorithm would demand the output parameter to be
be a writable forward range. A range find algorithm would
look for a subsequence within a bigger sequence.
(Like in the string algorithms)

-Thorsten