C++ does not define the size of a long. It defines constraints on the size of a long in [basic.fundamental]:
- It must be at least 32 bits wide.
- It must be at least as wide as an
int. - It must not have greater width than a
long long.
Note that the width of an integer type is not the same as its size. An integer type may have additional padding bits that are not part of the value.
It’s up to the implementation to define the precise widths of the data types it supports.
Oh, and I’m not sure why you call 32 bits a “short.” A short can be as small as 16 bits by the language definition.
Notice there’s no reference to “64-bit C++” anywhere in that definition. “64-bit C++” isn’t really a thing, as least as far as the language standard is concerned. There are platforms that call themselves 64-bit, and C++ compilers that target those platforms.
Now, it so happens that Windows has chosen to define long as 32 bits for its 64-bit x86 targets. MacOS, Linux, and UNIX have chosen to define long as 64 bits for 64-bit x86 targets.
I see nothing wrong with this. This is how the language was designed: Each platform chooses what makes the most sense for that platform.
I’m sure Microsoft has good reasons for its selection. Perhaps they felt it was the cleanest path for migrating existing C++ code from 32 bit platforms to 64 bit platforms. Perhaps there’s a blog post or two out there that details the reasoning.
Oh wait, there is:
- Why did the Win64 team choose the LLP64 model? | The Old New Thing
- Abstract Data Models (archive copy of a broken link in the first blog post)
Quoting from the second link:
Initially, the team expects most applications that run on 64-bit Windows to have been ported from 32-bit Windows. It is a major goal of the team that the same source, carefully written, should run on both 32- and 64-bit Windows. Defining the data model does not make this task easier. However, ensuring that the data model affects only pointer data types is the first step. The second step is to define a set of new data types that allow developers to automatically size their pointer-related data. This allows data associated with pointers to change size as the pointer size changes from 32 bits to 64 bits. Basic data types remain 32 bits in length, so there is no change in the size of data on the disk, data shared over a network, or data shared through memory-mapped files. This relieves developers of much of the effort involved in porting 32-bit code to 64-bit Windows.
Huh, so there you have it. Indeed, this selection was made in order to ease migration from 32-bit to 64-bit Windows! Imagine that.
I’m willing to bet that, even today, there’s more lines of code out there now, still in use, that were developed on 32-bit Windows than on 64-bit Windows.
Disgraceful? Hardly.
And besides, you have a 64-bit type available for when you need it: long long.