Cross-platform: selecting data types to use 32/64 bit
I am experimenting with 开发者_运维技巧my first cross-platform application that needs to run on Linux Redhat 5.3 and also on Windows XP/Vista/7.
As some OSes will run x86 or 64, I am wondering about what data types to declare.
I don't want to use any libraries to achieve cross-platform portability; I would like to experiment by myself first.
If I need a int, should I declare int32 or int64 or just int?
If I was to compile on a 64-bit OS and use an int32 then the would the data be truncated to a 32 bit value so I would lose some data?
I am wondering how I should declare if I run on different OSes with different architectures.
In many 64-bit OSes (such as 64-bit Linux), ints are still only 32 bits wide; only longs and pointers are 64 bits wide. This is referred to as an LP64 data model. The reason for this is that in many cases, an int does not need more range than is provided by 32 bits, and using 64 bits would only waste memory. Under 64-bit Windows, evens longs are 32-bit (for compatibility with 32-bit Windows), and only long longs are 64-bit; this is referred to as an LLP64 data model.
If your application is going to be running on 32-bit as well as 64-bit operating systems, then the range of a 32-bit integer is obviously sufficient -- otherwise, you would be in trouble on the 32-bit OS. So just go ahead and use ints in those cases. If you can identify cases where you need the range of a 64-bit integer, use an int64_t
(defined in stdint.h
) explicitly. To make sure the binary data formats you write to disk are compatible across platforms, use int32_t
and int64_t
explicitly in those places... but also be aware of potential endianness issues.
Finally, when writing 64-bit code, be aware that pointers cannot be converted to ints in a LP64 data model -- so use uintptr_t
instead.
If you code cleanly, 32-bit/64-bit portability should be almost a non-issue -- there's not really much more you need to be aware of than what I've written above. Portability between Windows and Linux will generate much greater issues that portability between 32-bit and 64-bit.
If you need an integer, type int
, and so on. If you need to make assumptions about what a data type can hold (such as, you require that it has 32 bits), check out stdint.h
As long as you make sure you aren't making assumptions about what a data type can hold, you'll be in good shape. The moment you do something like assume a data type will hold n bits, you're into implementation defined land, where you need to make sure it works on both platforms.
In most cases, you don't need a fixed size - you just need a minimum size. The plain old C data types do have such minimum sizes (ranges):
type | minimum size
-------------------+---------------------------------------------
char | at least 8 bits (but see below)
signed char | -127 to 127
unsigned char | 0 to 255
short | -32767 to 32767
unsigned short | 0 to 65536
int | -32767 to 32767
unsigned int | 0 to 65536
long | -2147483647 to 2147483647
unsigned long | 0 to 4294967295
long long | -9223372036854775807 to 9223372036854775807 (see below)
unsigned long long | 0 to 18446744073709551615 (see below)
(char
must have the same range as either signed char
or unsigned char
. long long
and unsigned long long
are new to the C99 specification, but are present as an extension in many compilers supporting only the old standard).
Use whichever size is big enough to fit the ranges of values you're interested in, plus size_t
for sizes of objects / number of objects / array indexes, and you'll be right in most cases.
The additional type values in <stdint.h>
can be useful, but should be used sparingly.
You need to use a data type appropriate for the data you are handling, and as you want to be sure that doesn't change across platforms use uint32_t, uint16_t etc from stdint.h
Most important is if you are manipulating a value whose size will vary with the underlying architecture e.g. the size of container, you should use size_t as it will adapt to compiler target e.g. 32 or 64 bits.
精彩评论