Just something I've read and would like clarified...


I've been using the smallest sized variables possible because I thought it saved memory (ie. 8 and 16 bit integers). Should I be using 32 bit integers instead, since I have a 32 bit processor? Should I add macros to use 64 bit integers on 64 bit processors?

Yes, using smaller types will typically reduce the memory; however, it highly depends.

Take the stack, for example. Everything on the stack is actually the native size of the CPU. So, if you just have a char in a function, you really didn't save any memory at all.

Compilers will typically add padding to structures as well, to promote the size of the struct to a multiple of the CPU bit size. They usually do this, since it'll allow the data to be copied in far less cycles then a non-aligned struct.

I personally like to just use the standard types (char, short, int, long, ect...), since I typically find that it doesn't really matter. As long as you can guarantee that the type you choose can hold the values you need, you are fine.

One of the common things I see in open source projects, that I hate, is the use of specific type sizes (originally I wasn't going to talk about this, but since you brought it up..). Take int32_t, for example. In nearly every situation I've seen, there was never a need for 32bits integers. In fact, more then likely, a 16bit integer is more then enough. The problem with defining the number of bytes, is that it does not scale at all. On a 16bit CPU, int32_t is now a very slow type. Plus, the 16bit CPU is far more limited in things like memory, so those extra 16bits aren't going to do you any good. Now take a 64bit cpu. Again, int32_t is a slower type. Plus, here are you limiting your program to handle up to 32bits.

If you just use the native type, and let the compiler handle size restraints, then your program will scale far better. Not to mention that it'll generally have better performance.

Here is a general table of the types, and what I use them for



A WORD is typically the size of the CPU bits. IE, that translates to a int, which does scale far better.

This post has been edited by Cerolobo: 18 Jul, 2008 - 10:16 AM

Thanks, that was a really good explanation.

I didn't know that about fixed-width integer types. I'm probably not going to go through Dagger3d and switch all of them, but I'll keep what you said in mind for future projects.

Depends on the compiler, On GCC 64-bit, long is 64-bits but on MSVC++ it's 32-bits, int on Borland C++ 3 is 2 bytes and long is 4. int now is pretty much 32-bits now except on ancient 16-bit compilers. If you want to be portable in sizes use the fixed types such as int32_t/__int32.

Ok, I should rephrase that. It really does depend on the data model the compiler is using.

for 16 bit, ints are typically 16 bits
for 32 bit, ints are typically 32 bits

64 bit is where it starts to get messy. The bulk of the 64 bit compilers I've seen, use the LP64 data model. Wikipedia actually has a decent article on 64 bit data models

http://en.wikipedia.org/wiki/64-bit#64-bit_data_models

My point is that using int32_t and similar don't really give you any benefit. If you explicitly require 32 bit variables, then yes, you should use it. However, more then likely, you don't. If you do use the standard type, the data types will more then likely scale with your program.

32 bit and 64 bit are very common today. If you are going to target these platforms, then using long in place of int will allow the variable to scale automatically to your platform (assuming LP64 data model). In 16 bit, however, it will be a slower type.

If you really do care about the size of your data types, you should use your own defines. To me, using things like int32_t tells me that you are only designing your program to run on a specific platform.