Why is size_t unsigned?

[Regan Heath]

On Mon, 22 Jul 2013 04:47:34 +0100, JS <js.mdnq at gmail.com> wrote:

> Doing simple stuff like
>
> for(int i = 0; i < s.length - 1; i++) fails catastrophically if s is  
> empty. To make right one has to reduce performance by writing extra  
> checks.
>
> There seems to be no real good reason why size_t is unsigned... Surely  
> one doesn't require too many strings larger than 2^63 bits on an x64  
> os...
>
> I running into a lot of trouble because of the way D deals with implicit  
> casting of between signed and unsigned.
>
> please don't tell me to use foreach... isn't not a panacea.

I have always found the whole size is an unsigned int thing annoying too.   
In C/C++ I simply cast strlen() and co to 'int' because in all but very  
specific and well known cases this is entirely sufficient, and it avoids  
the underflow issue entirely.

If we were to design the perfect type for representing a size or length it  
would hold the maximum value of an unsigned int, but would not undeflow to  
max unsigned int, instead it would truncate.

This type would have to be built on top of the existing primitives and  
would therefore be less performant, which is a shame and likely the reason  
it doesn't already exist.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/