range and algorithm-related stuff

[Denis Koroskin]

On Sun, 25 Jan 2009 23:32:13 +0300, Christopher Wright <dhasenan at gmail.com> 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.
>
> 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 belive he was talking about random-access ranges.
A range.subrange() could also be const, though.