Maybe a bit OT as not at all game related but still C/programming/library related.

I've been compiling a lot of originally linux/unix libraries and programs on Win64 lately and it works without too many problems except for one recurrent warning happening a massive amount of time, eg:

AFAIK size_t is 8 bytes on win64, 4 bytes on x64-linux, is that correct?

No, it's 8 bytes in 64-bit Linux as well.

If you can edit the code, you can use an explicit `static_cast<int>(...)' to tell the compiler that you know what you are doing (even if you don't ).

I still wonder if there is a one-size-fits-all approach to tackle this, maybe defining size_t as something else or should I in theory replace all occurrences on a 1 by 1 basis to determine whether a 64-bit or 32-bit is appropriate there? That would be a massive amount of work and I kinda wonder how win64 seems to only be an afterthought even now in 2016.

size_t is a type defined in the standard library. How exactly would you redefine it?

The correct approach is to store size_t values in variables of type size_t. Everything else is based on assumptions that may or may not be valid.

That being said...I do not care much about that in personal projects. size_t is equivalent to unsigned long long (64 bit uint) in MSVC x64 and I have never needed more than INT_MAX entries within a single container, so casting to int just works. The only case where it may matter is file handling; there certainly is software working on files larger than 4GB.

By the way: C# uses signed types for container lengths, which is IMHO a much better approach (and the long variants of Count and Length use a signed 64 bit integer, which is more than enough -- they only return the value in range [0,2^31) as a long, see below).

AFAIK size_t is 8 bytes on win64, 4 bytes on x64-linux, is that correct?

No, it's 8 bytes in 64-bit Linux as well.

If you can edit the code, you can use an explicit `static_cast<int>(...)' to tell the compiler that you know what you are doing (even if you don't ).

Ah I was not sure about that as I program on Windows only (will try to do Linux later as well)

So this means that if you compile these libs/progs on Linux as target x64, GCC should spit out the same warnings right?

Does it mean that what I'm trying to compile was never meant to go x64 in the first place? I know PHP at least says only PHP 7 has x64 truly in mind and that before that,eg PHP 5.6.x, it was "experimental, use at own risk".

C# uses signed types for container lengths, which is IMHO a much better approach

I'm curious why you think this is a better approach?

You aren't alone in thinking that - Java doesn't even have unsigned integer types. Which leads to support libraries for when you need unsigned integers, and incredible oddities like limiting array length to 2^31 even on 64-bit systems...

C# has unsigned types and I recognize their usefulness, especially for low-level bit manipulation. I have looked up NET array limitations - they are in fact limited to 2^31 elements. Apparently individual NET objects are limited to 2GB by default anyways, so this is a deliberate runtime limitation...

Regarding C++ I don't see the problem though. Consider that I'm by no means a professional programmer, so this comes more down to preference. Here are some things that strike me as odd:

• numeric literals are signed by default
• the default go-to type of the language is signed int
• unsigned int vs int comparison forces conversion to unsigned, making accidental unsigned vs signed comparisons dangerous (who hasn't been bitten by this?)
• if I need more than 2^31 elements right now, I would naively expect to need more than 2^32 at some point in the future.
• You can possibly return error codes in the negative space. Ok, you probably won't for methods like size()
• I always have the odd feeling that unsigned behaves a bit parasitic, forcing other things it interacts with to unsigned, too.
• Most of the time a signed int is enough for my uses

Well, I guess most of this unsigned vs signed behavior is there to make the language efficient for as many architectures as possible. I usually don't want to perform math on unsigned values; most of the time I want to operate on signed values. In most of my code I still simply cast size_t to int and call it a day. If I needed larger containers, I'd cast it to long and call it a day. I'm not writing security-critical code, I'm writing games

I'm always confused why people find size_t being unsigned to be a problem. Why are you performing signed comparisons on array indices in the first place? There are very few valid use-cases thereof.