range and algorithm-related stuff

[Denis Koroskin]

On Mon, 26 Jan 2009 23:37:25 +0300, Denis Koroskin <2korden at gmail.com> wrote:

> Steven Schveighoffer Wrote:
>
>> "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.
>> >
>>
>> Ranges are structs.  It should not matter if you want to make some  
>> const and
>> some non-const.  Basically, it depends on the range implementation.  If  
>> you
>> can make it const, make it const, if not, don't make it const.  It  
>> shouldn't
>> break any APIs.
>>
>> For example, an array range might have empty be const, but a stream  
>> range
>> might not.  What matters is what functions you can use those ranges in,  
>> but
>> those are generally templated functions, so the compiler will tell you
>> whether it can be used or not when it tries to compile it.
>>
>> Personally, I see no benefit to having empty() be const.  What benefits  
>> do
>> you gain by specifically making empty const and the other functions not
>> const?  Presumably, the underlying container must be not const in order  
>> for
>> head, next, etc. to work properly, so there is no requirement there.
>>
>> -Steve
>>
>>
>
> Checking if a range is empty() prior to accessing its head is useful. If  
> empty() is const, you can't do that.

Err.. if empty() is not const and you have a const range reference.