Re: Why is the return type of count_if() "signed" rather than "unsigned"?
Daniel Pitts wrote:
On 6/22/2010 4:05 PM, Paavo Helde wrote:
Here, the correctness would be potentially jeopardized only if one
has an array of 1-byte objects, which is larger than half of the
adressable space (in flat addressing mode). This is a very special
case, most probably encountered in some OS kernel code, and it
would be hard to imagine why kernel code should want to count all
of the address space bytes with count_if(). So I guess the
consistency here overweights the concerns of potential
incorrectness.
Actually, you could also have a container who's iterators iterate
over a non-memory resource (such as a socket stream or file). Just
because you can't load everything into memory at once doesn't mean
you can't iterate over it, or have a container abstraction around
it. So it isn't such a special case after all.
On a 32 bit system an unsigned value lets you count the bytes in a 4
GB file, instead of a 2 GB file. What if you need to count the bytes
of a 5GB file?
One extra bit only gives you twice the range, which is not much of a
difference - otherwise we could have had 33 bit computers. So it is a
special case!
What concerns of compiler warnings of using the result with size_t
and friends this is the fault of size_t that it is unsigned. This
is an old war^B^B^B discussion, and I only know of people who have
run from the unsigned camp to the signed camp (me included). YMMV,
of course.
While I comprehend your argument, and I was almost fooled by it
briefly, I think that it is incorrect for never-negative values to
be stored in a signed container when an unsigned container of
appropriate size is available.
This is where it gets religious. I'll pass.
Bo Persson