Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk