Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at