integer sizes

[Rioshin an'Harthen]

"Jason House" <jason.james.house at gmail.com> wrote:
> Once upon a time, I thought I read that D was trying to clean up confusion 
> of integer sizes, for example, this link 
> http://www.digitalmars.com/d/type.html gives specific sizes that match a 
> typical x86 machine.
>
> Now that I'm developing for both 32bit and 64bit systems, I start to 
> wonder what to type by default so that it's efficient on all the machines.
>
> When I read http://www.digitalmars.com/d/portability.html, I see what I 
> started with in this e-mail is wrong.  Integral sizes could be increased. 
> Does that mean sizeof(int) and sizeof(long) will ever match? Or does that 
> mean that if sizeof(int) increases, so will long and cent?    I don't know 
> about others, but having sizeof(cent) != 128 seems really strange, even if 
> it is a hypothetical feature.

True, it says that the sizes are to be taken as a minimum. However, later on
when dealing specifically with 32-bit to 64-bit portability, it says:
"Integral types will remain the same sizes between 32 and 64 bit code."

> I see that size_t and ptrdiff_t represent an integer of sufficient size to 
> span the address space.  There's no types for natively sized integers.  Is 
> it safe/best to assume that int is of native size?  Should I start adding 
> my own alias for native integers?  (maybe nint)

size_t and ptrdiff_t represent the natively sized integer types: on a 32-bit
machine size_t is the same type as uint while ptrdiff_t is the same as int,
on a 64-bit machine they're ulong and long, respectively.

So if you need a specific bitsize for an integral type, use the standard 
byte,
short, int, long, cent, or their unsigned variants, while if you need the 
correct
native type use ptrdiff_t for signed values and size_t for unsigned.