www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - integer sizes

reply Jason House <jason.james.house gmail.com> writes:
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.
May 28 2007
next sibling parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"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.
May 28 2007
parent reply Jason House <jason.james.house gmail.com> writes:
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.
May 28 2007
parent torhu <fake address.dude> writes:
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.
May 28 2007
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
May 28 2007