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

From: Eric Niebler (eric_at_[hidden])
Date: 2005-03-14 14:17:45

David Abrahams wrote:
> "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.

By "something like that" do you mean a complete range-based algorithms 
library? I have started one at:

http://tinyurl.com/4ql8w
http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&filename=range_ex.zip&directory=eric_niebler&

See http://boost-sandbox.sf.net/libs/range_ex for partial docs.

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

Maybe we should put our heads together.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com