From: Eric Niebler (eric_at_[hidden])
Date: 2005-03-14 14:26:37
Thorsten Ottosen wrote:
> "Eric Niebler" <eric_at_[hidden]> 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 = copy_range<int>(aRange); // oops, can't return array
> if we had
> template< class T, class Range >
> T copy_to_seq( const Range& r )
> T t;
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk