Thorsten Ottosen <tottosen@dezide.com> writes:
David Abrahams wrote:
Thorsten Ottosen <tottosen@dezide.com> writes:
Eric Niebler wrote:
right, but do you also waht sort() to return the sorted range?
Yes, but as a "reference" to the original, i.e. a boost::range iterator bundle.
I assume you mean iterator_range< range_iterator<Rng>::type > or something similar.
Yes.
There are lots more issues with range algorithms that have not been discussed yet. What about algorithms that accept an output iterator and write into it? Will they now take an output range?
My say would be no. We still have the concept of an unbounded iterator.
There is also the issue of O(1) size, for which you have not got support in your concept hierarchy.
Did I forget to mention this? Anyway, size() is now O(1). If you want a generic version, dictance(rng) is supplied instead.
That's not what I mean. Is there a way to distinguish, at compile-time, a range that has support for O(1) size from one that does not? One needs that for important "benefit and beauty"-destroying optimzations that you dislike so.
And then there's property maps.
How do they relate to this?
They're an important part of a generalized range concept.
And what does br::copy return? You might think the answer is easy: the range designating the unused elements at the end of the second range. But what if br::copy is range-checked and truncates? That return value is no longer sufficient -- if br::copy returns an empty range, did the algorithm truncate, or did it all just fit?
I'd be quite happy with copy returning void.
I think that's a mistake.
What do you want it to return then?
A range. I'm not sure which range. But I guess I'm not thinking too carefully about that one, so I retract my previous statement. I just don't know. -- Dave Abrahams Boost Consulting www.boost-consulting.com