David Abrahams wrote:
Thorsten Ottosen <tottosen@dezide.com> writes:
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.
ok, if range_category<R>::type is convertible to std::random_access_iterator_tag, then you may call boost::size(rng)
And then there's property maps.
How do they relate to this?
They're an important part of a generalized range concept.
perhaps, but its hard for me to see how and why they are it. how do you imagine that property maps would affect the interface of range-based algorithms? isn't range concepts orthogonal to PMs? -Thorsten