I''m wondering how safe it is to assume that a char is ALWAYS 8 bits, a short is 16 bits, and a long is 32 bits. I know int has an unreliable size. The reason I ask is because I would like for my data files that are to be used with my in-progress game engine to stay portable should I ever try to get this code running on a different platform. And, just out of curiousity, what would the standard way to declare a 64-bit int on a 64-bit architecture? long long? Thanks.

No it''s not safe to assume that. Other platforms can have different size, the best thing to do is create typedefs do the data type size you need.

example :

#ifdef WIN32

typedef int MY32bits;

#ifdef OTHERMACHINE

//for this machine double is 32 bits

typedef double MY32bits

#endif

char : always 8 bits
short : always 16 bits
long : always 32 bits
int : depends on the system (32 bits under Win32 and UNIX (perhaps not ALL UNIX, i''m not sure))

float/double -> not sure!

So, if you don''t need float/double, just use char/short/long and it should work on all platforms.

Commonly used Windows SDK and MFC data types are as follows:

BOOL A Boolean value.

BSTR A 32-bit character pointer.

BYTE An 8-bit integer that is not signed.

COLORREF A 32-bit value used as a color value.

DWORD A 32-bit unsigned integer or the address of a segment and its associated offset.

LONG A 32-bit signed integer.

LPARAM A 32-bit value passed as a parameter to a window procedure or callback function.

LPCSTR A 32-bit pointer to a constant character string.

LPSTR A 32-bit pointer to a character string.

LPCTSTR A 32-bit pointer to a constant character string that is portable for Unicode and DBCS.

LPTSTR A 32-bit pointer to a character string that is portable for Unicode and DBCS.

LPVOID A 32-bit pointer to an unspecified type.

LRESULT A 32-bit value returned from a window procedure or callback function.

UINT A 16-bit unsigned integer on Windows versions 3.0 and 3.1; a 32-bit unsigned integer on Win32.

WNDPROC A 32-bit pointer to a window procedure.

WORD A 16-bit unsigned integer.

WPARAM A value passed as a parameter to a window procedure or callback function: 16 bits on Windows versions 3.0 and 3.1; 32 bits on Win32.

I know it''s a bit off the topic, but I always wanted to do this

Of course, if you''re working with VC++, you could use _int8, _int16, _int32, _int64

You know, I never wanted to be a programmer...

Alexandre Moura

quote: Original post by Prosper/LOADED


char : always 8 bits
short : always 16 bits
long : always 32 bits
int : depends on the system (32 bits under Win32 and UNIX (perhaps not ALL UNIX, i'm not sure))

float/double -> not sure!

So, if you don't need float/double, just use char/short/long and it should work on all platforms.

No, nope, and incorrect. The ANSI C native types are not guaranteed to be of particular size. What is guaranteed is the following:

sizeof(long ) >= sizeof(short ) >= sizeof(char )

int is usually same size as long or short , but that's platform/compiler choice.

sizeof(double ) >= sizeof(float )


What you should do is use your platform/compiler's environment header (or create your own) similar to what Gorg and alexmoura have previously stated.

If you are doing cross-platform and need to ensure various data types are the same size, create a check function and run it first thing from your main(). Something like this:

    //assume you have some typedefs naming your types, such as//uint8 for 8-bit unsigned int, or sint32 for 32-bit signed int  void check_types(){  //type names' number is bit count; sizeof returns byte count    assert(sizeof(uint8 ) == 1);  assert(sizeof(sint8 ) == 1);  assert(sizeof(uint16) == 2);  assert(sizeof(sint16) == 2);  assert(sizeof(uint32) == 4);  //...etc...}  int main(){  check_types();  //...everything else...}    

If you have your assert() macro/func defined properly, they will not generate code during release builds, and the entire call to check_types() should be optimized out.

---- --- -- -
Blue programmer needs food badly. Blue programmer is about to die!

Edited by - mossmoss on July 29, 2000 10:30:43 AM

Thanks for all the responses guys. I had been using typedefed types to avoid these potential problems. Looks like I made the right choice.