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

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-14 13:01:00

"Eric Niebler" <eric_at_[hidden]> writes:

> 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.

I am about to start writing something like that.  In order handle
these things generically you have to be able to have ranges defined by
start and end iterators of differing types.  See, for example, Fusion.
The utility of that idea goes beyond tuples, though: iterators into an
array can encode their positions and thereby enable full compile-time
loop unrolling.  For the case of output iterators, one could simply
form a range accepting a "universal end iterator" object; a
non-dereferenceable forward iterator type that can be compared with
anything.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com