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

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-14 14:47:58

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

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

Yes, let's.  I'll forward you some other thoughts.

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