range and algorithm-related stuff

[Denis Koroskin]

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.