Thou shalt have no other gods before the ANSI C standard 1643

Douglas A. Gwyn

I couldn't find this file in my install of MSVC++ (which affects my Intel C++, of course), WATCOM C-C++ or even Turbo C.

int32t, for all intents and purposes, does not exist, since there is no widely deployed include file where such a thing has ever been defined, and its not built into the language core. The vast majority of actually existing platforms encode int as 32-bit 2s complement, and every platform with a wide developer audience from this moment forward will define it to be that way.

Well, more specifically, performance is not even necessarily about that. This is just some concept that has been carried forward since the 70s, even when it no longer applies. Performance, as you suggest, does not necessarily come from these sorts of details.

Being able to rely on the size of your underlying datatypes leads to improved programmer productivity. Bending over backwards to please the compiler-platform vendor's anonymity doesn't serve anyone's needs except those of the compiler-platform vendor.

Only on compilers and platforms that are not up to the task of dealing with this.

You should notice that the x86 has a floating point model which is, shall we say, has been historically very difficult to perfectly map to the intended standard float-double usage in C programs. The compilers and CPU vendors rose to the challenge, and today nobody can say x86's are not up to snuff on floating point (either because x87 is just so fricking fast, or because of the sneaky switch to SSE-2 that has started and will likely complete slowly, almost imperceptably, over the next decade).

Mohammed (the compiler and platform vendors) moved to the Mountain (the developer community.)

As to the question of speed -- leaving int as 32bits is the best general speed compromise. Going below 32bits will cause the entire programming community to have a hissy fit and cause them to return longs or doubles anyways. Go above and all of a sudden you've doubled the pressure on the CPU's cache. So what developers want corresponds to the fastest way of getting there. This is why AMD, Intel, IBM-Motorola, Dec and Sun left int as 32 bits in all of their different 64 bit architectures -- besides the developer outcry, they knew it was the fastest solution as well.

Your comment applies at best to some extremely underpowered 16 bit environments, where the kinds of things that are performance considerations are a throwback and is something that will run *counter* to the needs of developers. People in such marginal environments tend to be more willing to compromise on standards compliance anyways, since there's usually some other compelling reason (extremely low power, or special instructions) to want to use such a processor.

--- Paul Hsieh