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