Depends, if you want to write a program that you can compile with every compiler, then yes, you have to worry, or be very very conservative in assumptions about 'int' size. If you only care about your current compiler, it's likely not to change, so you can worry less.

You can also not use 'int' and use standard types for integers where you need a certain size, eg std::int32 is 32 bit signed integer always.

I agree with Alberth, you should use explicitly sized int16 32 etc. I was on a system where plain int was 64

Isn't this sort of situation the reason they drum into us to use sizeof(int)?

7 hours ago, DividedByZero said:

Isn't this sort of situation the reason they drum into us to use sizeof(int)?

If one was feeling super-pedantic, one would note that sizeof(int) doesn't tell you how big an int is, only how many times bigger than char it is, and thus two architectures returning 4 could have different sizes of interest, and architectures returning different sizes can have the same size int.

Having non fixed sizes for the basic types is an 'interesting' design decision. It makes it highly likely that any non-trivial code written for one platform will break when compiled on another (e.g. integer overflows, file compatibility). On the flip side it could *potentially* help when a platform is really bad at handling some specific type, or help with alignment.

In practice a lot of people doing cross platform stuff do something like the following:

// Not sure on the requirement for all platforms to support this
// may be POSIX stdint.h
typedef uint64_t u64;
typedef int64_t s64;
typedef uint32_t u32;
typedef int32_t s32;
typedef uint16_t u16;
typedef int16_t s16;
typedef uint8_t u8;
typedef int8_t s8;

There are other issues too, particularly pointers between 32 bit and 64 bit, where you might use e.g.

// these can be 32 or 64 bit depending on platform
ptrdiff_t
size_t
intptr_t
uintptr_t
time_t

However for file compatibility you may need to come to a compromise, e.g. store 64 bit pointers in files on 32 and 64 bit. Another issue to address can be to standardize endianness in netcode and files.

Alignment also often needs special care on different compilers / platforms. Some hardware (e.g. some ARM) will crash if you try and load certain data types that aren't aligned to a certain boundary, which would work fine on x86.

You can also have problems where on one platform a 'char' defaults to a signed char, and on another an unsigned char (PC versus NDK).

20 hours ago, _WeirdCat_ said:

But do i really have to worry that much?

If you expect all your clients to use the same computer architecture, which is often the case, then you really don't need to worry.