Why is the C++ "int" type so used instead of "short"?
Author
I've been wondering, why is the "int" type so used instead of "short" (or even "byte") in some cases? I see many situations where the system would take benefit from the fact that I don't need a screen resolution from -2,147,483,648 to 2,147,483,647 (inclusive :) ), just something between -32,768 and 32,767. Examples: OpenGL and SDL functions (won't list them here).
Thanks!! (just curious [wink])
It won't matter much in your system if an int is 4 bytes or 2 because your registers are all 4 bytes, so it will just take one count to put it in the register. It won't optimize speed, just slightly help the space your program takes up.
Although using smaller values is more efficient space-wise, it is less efficient time-wise.
If the registers are 32-bits and you copy into it a 16-bit number then the program needs to add an extra instruction to convert the 16-bit number into a 32-bit number. e.g. -2 is 0xFFFE as a short, but must be converted to 0xFFFFFFFE as a long, rather than just 0x0000FFFE which is 65534, not -2! This can add up to a lot of extra CPU instructions being executed.
There's more to it than that, but as you can see if your data type matches the register size then everything is simple.
I admit that for many applications space can be more important than speed. Using smaller datatypes for those applications is up to you, but as this is a game dev site you'll probably find most people here will prefer to take the faster option.
If the registers are 32-bits and you copy into it a 16-bit number then the program needs to add an extra instruction to convert the 16-bit number into a 32-bit number. e.g. -2 is 0xFFFE as a short, but must be converted to 0xFFFFFFFE as a long, rather than just 0x0000FFFE which is 65534, not -2! This can add up to a lot of extra CPU instructions being executed.
There's more to it than that, but as you can see if your data type matches the register size then everything is simple.
I admit that for many applications space can be more important than speed. Using smaller datatypes for those applications is up to you, but as this is a game dev site you'll probably find most people here will prefer to take the faster option.
Quote:Although using smaller values is more efficient space-wise, it is less efficient time-wise.
You forgot padding. On most recent PC, all data is aligned to 4-bytes boundaries. So why use 2-bytes datatypes instead of 4-bytes ones ? That's the real reason why one would use int instead of short.
Anyway, in C, nobody's guaranteed that ints are 4-bytes, it depends on the architecture. If you *do* want your data to be 4-bytes regardless of the architecture, then use long instead of int.
But, the one real reason i think of why are we all using int instead of long or short, is that it's faster to write :)
Quote:Original post by flureQuote:Although using smaller values is more efficient space-wise, it is less efficient time-wise.If you *do* want your data to be 4-bytes regardless of the architecture, then use long instead of int.
Even then you're not guaranteed. It's entirely possible for a fully compliant implementation to have 1 byte longs.
Quote:Original post by Polymorphic OOPA long is guaranteed to be capable of holding at least a 32-bit (one's complement) integer. However it could use the same size as a byte if you define a byte as the smallest addressable unit (i.e. char).Quote:Original post by flureQuote:Although using smaller values is more efficient space-wise, it is less efficient time-wise.If you *do* want your data to be 4-bytes regardless of the architecture, then use long instead of int.
Even then you're not guaranteed. It's entirely possible for a fully compliant implementation to have 1 byte longs.
The general rule is: sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long). Where char has a minimum range of at least -127..127, short has a range of -127..127, int has a range of -65535..65535 and long has a range of -2147483647..2147483647.
Quote:Original post by flureNot necessarily, compliers only makes sure that the data itself is properly aligned in relation to it's size (up to a limit of 8/16 bytes or so).
You forgot padding. On most recent PC, all data is aligned to 4-bytes boundaries. So why use 2-bytes datatypes instead of 4-bytes ones ? That's the real reason why one would use int instead of short.
So an array of shorts won't take up 4 bytes per element or require an initial 2 bytes of padding, and a structure without larger elements or with two shorts in a row will not require any extra padding
I just wanted to say this because of the many misconceptions about how alignment really works. And thus cause problems whenever dealing with raw structure io, communicating with assembly language or simply trying to save some memory.
i always though int float char ... are the standard system types and if you recompile your code on e.g. nbit compilers they ll make e.g. int to nbit float to nbit char to 8, long to 2n short to n/2
therefore you shall use _int64 _int32 _int16 if you need a fixed size integer on all platforms
please correct me if i am wrong
therefore you shall use _int64 _int32 _int16 if you need a fixed size integer on all platforms
please correct me if i am wrong
Assuming there is a Microsoft compiler for said platform, __int? might work. Those particular keywords are listed as Microsoft-specific (though it does sound like a useful tool for other compilers/IDEs to implement - especially for file I/O).
It depends on what you are doing with the data. If you are storing tons of them, then space is an issue. If not then it doesn't matter, you're building in redundancy for later on.
In anycase just be warey of premature optimisation, you could shoot yourself in the foot later on.
In anycase just be warey of premature optimisation, you could shoot yourself in the foot later on.
"__int8" = 8 bit number, equivilent to "char"
"__int16" = 16 bit number, equivilent to "short"
"__int32" = 32 bit number, equivilent to "long" (and "int" with 32 bit compilers)
"__int64" = 64 bit number
"__m128" = 128 bit number representing 4 floats packed together
when data is stored in a continuous fashion eg.
int a;
char b;
long c;
short d;
double e;
the size will be padded out to the nearest dword value, that is a 32 bit value, this is the same with arrays.
the above will be allocated memory like so.
4bytes + 1byte + 4bytes + 2bytes + 8bytes = 19bytes + <padding to dword> = 20bytes
loading a 4 byte number into a register
long a;
__asm mov eax, a
loading a 2 byte number into a register
short a;
__asm movzx eax, a
however the movzx instructions requires more cpu clocks than the mov instruction
"__int16" = 16 bit number, equivilent to "short"
"__int32" = 32 bit number, equivilent to "long" (and "int" with 32 bit compilers)
"__int64" = 64 bit number
"__m128" = 128 bit number representing 4 floats packed together
when data is stored in a continuous fashion eg.
int a;
char b;
long c;
short d;
double e;
the size will be padded out to the nearest dword value, that is a 32 bit value, this is the same with arrays.
the above will be allocated memory like so.
4bytes + 1byte + 4bytes + 2bytes + 8bytes = 19bytes + <padding to dword> = 20bytes
Quote:In anycase just be warey of premature optimisation, you could shoot yourself in the foot later on.This is very true
Quote:This can add up to a lot of extra CPU instructions being executed.actually untrue, see below:
loading a 4 byte number into a register
long a;
__asm mov eax, a
loading a 2 byte number into a register
short a;
__asm movzx eax, a
however the movzx instructions requires more cpu clocks than the mov instruction
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
