Notes IV

[Jarrett Billingsley]

"Jason House" <jason.james.house at gmail.com> wrote in message 
news:fn86eb$1h76$1 at digitalmars.com...

> I've never been all that happy with the fixed size thing...  I think sizes 
> should be compiler-dependent unless the user is explicit about what they 
> want.  That gives the compiler room for optimization on whatever the 
> hardware happens to be.  I'd actually like to see "int" be variable length 
> and have stuff like int8, int16, int32, int64 have set sizes.  In my mind, 
> it has the added benefit of making code that uses them more readable as 
> requiring a fixed size.

I actually agree with you.  The problem with the fixed size stuff is, well, 
for example:

for(uint i = 0; i < array.length; i++)
...

So this is now broken on 64-bit machines since arrays can be longer than 
what can be held in a 32-bit integer.  So we have foreach loops, but they 
can't necessarily be used in all circumstances.  If we have a case where we 
_have_ to use a C-style loop, we're stuck using the ugly, hard-to-type, 
badly-named "size_t" instead.  Keep in mind too that size_t is unsigned, and 
if you need a signed version -- it's ptrdiff_t!  Of course!

Another aesthetic issue is that qualitative names, like 'short' and 'long' 
don't make a lot of sense on architectures where the word length is > 32. 
On a 64-bit machine, 'long' is not long, it's "normal".  'int' is now short, 
and 'short' even shorter.

The idea Chris Miller and I share, is to have, as you've said, [u]int<n> 
types where <n> is an integer indicating the size, so int8, uint8, int32, 
uint128 (logical progression instead of "cent", yaay!), int36 (for PDP-10s) 
etc.  Then, the qualitative names become aliases for "sensible" int sizes 
based on the architecture.  On a 32-bit machine, [u]short is 16 bits, [u]int 
is 32, and [u]long is 64; on a 64-bit machine, [u]short is 32 bits, [u]int 
is 64, and [u]long is 128; on a PDP-9, [u]int would be 18 bits and [u]long 
would be 36 ;)  This also obviates size_t and ptrdiff_t, as [u]int takes 
their place as the "native word size".

This is all theoretical ranting, of course.