Christopher Wright wrote:
Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
I'm working on the new range stuff and the range-based algorithm. In
all likelihood, you all might be pleased with the results.
I wanted to gauge opinions on a couple of issues. One is, should the
empty() member function for ranges be const? On the face of it it
should, but I don't want that to be a hindrance. I presume non-const
empty might be necessary sometimes, e.g. figuring out if a stream is
empty effectively means fetching an element off it.
I have a hard time imagining a use for a const range.
Read-only arrays for example.
A range is essentially an iterator. It has to change its internal state
to move to the next element. So a const range will not allow you to
iterate over the members of a const array. It will allow you to iterate
over a single element, either once or an infinite number of times.
A range offering random access can give me any element without the range
actually changing.
You could change ranges to have "Range next()" rather than "void
next()", and that would allow you to use a const Range for reasons other
than checking whether it's empty. Iterating over a range would then look
like:
for (auto range = getRange(); !range.empty; range = range.next) {}
I don't see much purpose to this. If you want polymorphic ranges, you're
going to use a class for ranges. This will incur a lot of allocations,
which will be dog slow. The current design would only allocate once if
your range is a class.
I agree. Range.next currently mutates the range in-place.
Andrei