views:

126

answers:

6

I've been told that i should use size_t always when i want 32bit unsigned int, i dont quite understand why, but i think it has something to do with that if someone compiles the program on 16 or 64 bit machines, the unsigned int would become 16 or 64 bit but size_t wont, but why doesnt it? and how can i force the bit sizes to exactly what i want?

So, where is the list of which datatype to use and when? for example, is there a size_t alternative to unsigned short? or for 32bit int? etc. How can i be sure my datatypes have as many bits as i chose at the first place and not need to worry about different bit sizes on other machines?

Mostly i care more about the memory used rather than the marginal speed boost i get from doubling the memory usage, since i have not much RAM. So i want to stop worrying will everything break apart if my program is compiled on a machine thats not 32bit. For now ive used size_t always when i want it to be 32bit, but for short i dont know what to do. Someone help me to clear my head.

On the other hand: If i need 64 bit size variable, can i use it on a 32bit machine successfully? and what is that datatype name (if i want it to be 64bit always) ?

+3  A: 

size_t is for storing object sizes. It is of exactly the right size for that and only that purpose - 4 bytes on 32-bit systems and 8 bytes on 64-bit systems. You shouldn't confuse it with unsigned int or any other datatype. It might be equivalent to unsigned int or might be not depending on the implementation (system bitness included).

Once you need to store something other than an object size you shouldn't use size_t and should instead use some other datatype.

sharptooth
I'd also add that `size_t` is the type returned by the `sizeof` operator. However, in practice `size_t` is not *just* strictly for storing object sizes. For example, it is used by various standard library functions, such as `memcpy`, to store array lengths.
Charles Salvia
Eh, doesn't memcpy work on an `unsigned char[N]` ? I.e. there's no difference between array length and object size. Also, you'd often pass a `sizeof (struct T)` to `memcpy`, which makes sense only when you think of `memcpy` as taking an object size.
MSalters
+1  A: 

size_t is not always 32-bit. E.g. It's 64-bit on 64-bit platforms.

For fixed-size integers, stdint.h is best. But it doesn't come with VS2008 or earlier - you have to download it separately. (It comes as a standard part of VS2010 and most other compilers).

Since you're using VS2008, you can use the MS-specific __int32, unsigned __int32 etc types. Documentation here.

To answer the 64-bit question: Most modern compilers have a 64-bit type, even on 32-bit systems. The compiler will do some magic to make it work. For Microsoft compilers, you can just use the __int64 or unsigned __int64 types.

user9876
`size_t` existed long before 64 bits...I should know, I used it in Borland C++ compiler of late 1990's and early 2000s.
The Elite Gentleman
[Where is <inttypes.h> in Visual Studio?](http://stackoverflow.com/questions/1156267/where-is-inttypes-h-in-visual-studio-2005/1156285#1156285)
sbi
Generally, I'd suggest using the types in `<boost/cstdint.hpp>`, as they are available for VisualStudio and pretty much any other C++ compiler.
T.E.D.
@The Elite Gentleman: I've changed the first paragraph to try to clarify it. I was just using 64-bit as an example, since the question asker seems to think size_t is always 32-bit.
user9876
+2  A: 

As a side note: For containers, to indicate their size, don't use size_t, use container<...>::size_type

Armen Tsirunyan
I don't think so, except perhaps for embedded systems programming. For ordinary general code it adds verbosity, reduces clarity, and gains nothing. :-)
Alf P. Steinbach
@Alf: When writing generic code, this might be useful as you might want to include not only the standard containers but also some other STL-compatible container, for which the size_type might be unsigned short, for example. It does add verbosity, I agree, but I don't think it's a bad thing. Though obviously I should agree that I never write size_type myself. Unless in generic code
Armen Tsirunyan
+2  A: 

boost/cstdint.hpp can be used to be sure integers have right size.

Aleksander
A: 

Unfortunately, one of the quirks of the nature of data types is that it depends a great deal on which compiler you're using. Naturally, if you're only compiling for one target, there is no need to worry - just find out how large the type is using sizeof(...).

If you need to cross-compile, you could ensure compatibility by defining your own typedefs for each target (surrounded #ifdef blocks, referencing which target you're cross-compiling to).

If you're ever concerned that it could be compiled on a system that uses types with even weirder sizes than you have anticipated, you could always assert(sizeof(short)==2) or equivalent, so that you could guarantee at runtime that you're using the correctly sized types.

Your question is tagged visual-studio-2008, so I would recommend looking in the documentation for that compiler for pre-defined data types. Microsoft has a number that are predefined, such as BYTE, DWORD, and LARGE_INTEGER.

Take a look in windef.h winnt.h for more.

Nate
+2  A: 

size_t is not not necessarily 32-bit. It has been 16-bit with some compilers. It's 64-bit on a 64-bit system.

The C++ standard guarantees, via reference down to the C standard, that long is at least 32 bits.

int is only formally guaranteed 16 bits, but in practice I wouldn't worry: the chance that any ordinary code will be used on a 16-bit system is slim indeed, and on any 32-bit system int is 32-bit. Of course it's different if you're coding for a 16-bit system like some embedded computer. But in that case you'd probably be writing system-specific code anyway.

Where you need exact sizes you can use <stdint.h> if your compiler supports that header (it was introduced in C99, and the current C++ standard stems from 1998), or alternatively the corresponding Boost library header boost/cstdint.hpp.

However, in general, just use int. ;-)

Cheers & hth.,

Alf P. Steinbach