On Mon, 26 Jan 2009 23:37:25 +0300, Denis Koroskin <[email protected]> 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.
