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.

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)

I guess I sort of like the idea of int is always a native size and then having specific types such as int32, int64, etc...  I'm considering adding code which is very specific to integral sizes...  Depending of the case, I'd need to store anywhere between 49 and 361 bits.  When I start exceeding supported sizes, I have to start adding tricks...  I'd like to get it right for each machine.

"Jason House" <jason.james.house@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. 

Rioshin an'Harthen wrote:
> 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.

I believe there's some intel machines with have 64 bit pointers but 32 bit integers.  I'd assume that size_t would be 64 bits, but the desirable size for integers would still be 32 bits.  Using size_t in that scenario would be incorrect.

"Jason House" <jason.james.house@gmail.com> wrote in message news:f3f139$1hb8$1@digitalmars.com...
> 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.

I think the integer type sizes are fixed -- int will always be 32 bits etc. I think what that page is referring to is if you are to write your code using some kind of alias, like size_t, make sure you don't depend upon its properties on one platform.

Of course, this could also be a vestige from an ancient incarnation of D when integer sizes weren't fixed.

Jason House wrote:
> Rioshin an'Harthen wrote:
>> 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.
> 
> I believe there's some intel machines with have 64 bit pointers but 32 bit integers.  I'd assume that size_t would be 64 bits, but the desirable size for integers would still be 32 bits.  Using size_t in that scenario would be incorrect.

The C99 stdint.h header is available in both Phobos and Tango.  But even the GDC Phobos version of the std.stdint only seems to have been made to work with x86, x86_64, and PPC.  Only the pointer-sized types vary in size.  So you'd probably have to put some static asserts in your code no matter what.  Just in case they forget to update the file when gdc is ported to a new platform.

Docs:
http://www.digitalmars.com/d/phobos/std_stdint.html
http://en.wikipedia.org/wiki/Stdint.h

Maybe you can use the int_fast32_t type or something of that sort.  But it's not even guaranteed to be the fastest type on any given platform.