David Abrahams wrote:
"Eric Niebler" <eric@boost-consulting.com> 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