Thorsten Ottosen wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote in message
| But thinking of this | as a range conversion is the right way to go, IMO, except that it should | be called "range_cast" and it should be explicit.
hm..I dunno, the cast stuff implies some kind of extra work to me.
Could you explain this a bit?
| I agree this functionality is useful, but this is a rather unfortunate | interface choice, in my opinion. For instance, what if I want to copy to | an array: | | int rg[3] = copy_range<int[3]>(aRange); // oops, can't return array
if we had
template< class T, class Range > T copy_to_seq( const Range& r ) { T t; t.assign(begin(r),end(r)); return t; }
support of boost::array<T,size> could be ok.
copy(from, to). That's the idiomatic way of writing a copy function. What you have above is a conversion function, and typically we call those things casts.
| 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
The iterator interface suffers from either being slow or being unsafe, so I don't think that is the way to go either.
You're saying that either an output iterator is range-checked and it's slow, or it's not an it's unsafe. How is an output range any different? It's a sincere question -- I really don't know if output ranges have anything to offer above output iterators.
|. A | range-based copy algorithm should have a different interface and be part | of a complete range-based algorithms library.
yes, agreed.
We just need somebody to write those special range algorithms.
Have you missed it? I've got one in the sandbox, but it needs attention. -- Eric Niebler Boost Consulting www.boost-consulting.com