问题描述
C ++标准仅规定int必须至少为16位宽.至少根据 cppreference ，它几乎总是16或32位宽:
C++ standard says only that int has to be at least 16 bits wide. And at least according to cppreference, it's almost always either 16 or 32 bits wide:
data model int width in bits
----------------------------------
C++ standard at least 16
LP32 16
ILP32 32
LLP64 32
LP64 32
...
其他型号非常罕见.例如，ILP64(8/8/8:int，long和指针是64位)仅出现在某些早期的64位Unix系统中(例如Unicos on Cray).
Other models are very rare. For example, ILP64 (8/8/8: int, long, and pointer are 64-bit) only appeared in some early 64-bit Unix systems (e.g. Unicos on Cray).
是否有一个当前使用的系统的示例，其中C ++编译器的int宽度超过32位?当前使用的 是指某些特定的行业可能仍在积极使用某些旧系统，因为有充分的理由将其用于特定任务，并且无法合理地用其他东西替代.最好是，这将是正在积极开发/工作的东西，而不仅仅是运行遗留代码的系统，而这是20年来未曾涉及过的.例如，用于科学计算的具有64位int的现代系统也将是一个很好的答案.
Is there an example of a currently used system with a C++ compiler where int is over 32 bits wide? By currently used I mean e.g. some old system maybe still actively used by a specific industry because there's a valid reason to use it for that specific task and which cannot reasonably be replaced with something else. Preferably this would be something that's actively being developed/worked on, and not just a system running legacy code, which hasn't been touched in 20 years. A modern system with for example 64 bit int, which is used for scientific computing would also be an excellent answer.
我不是在寻找90年代使用过2年，然后完全弃置的系统.我也不是在寻找只用作玩耍的爱好的东西，或一些旧系统，这是世界上两家公司仅仅因为它们太便宜而无法升级而使用的系统.
I am not looking for a system that was used 2 years in the 90s and then dumped completely. I'm also not looking for something which is only used as a hobby to play around, or some old system, which two companies in the world use just because they are too cheap to upgrade.
推荐答案
请注意，此答案旨在解决框架挑战；即使有64个操作系统，由于几点原因，通常也不会想要32位以上的位.这意味着在没有考虑这些要点的情况下，团队不太可能会花时间去创建一个操作系统，甚至在这个时间点之前已经过时的可能性也很小.我希望找到一个更直接的答案，但是我认为这至少可以证明主要操作系统的决定是正确的.
Please note that this answer is intended as a frame challenge; that even 64 operating systems wouldn't normally want >32 bits due to several points. Which means it is unlikely a team would go through the effort of creating an operating system without already having taken into consideration these points and even less likely that it'd be non-obsolete by this point in time. I hope a more direct answer is found, but I think that this justifies at least the major operating system's decisions.
要开始使用，您正确的认为 C ++草案允许纯文本格式允许大于32位的整数.引用:
To get started, you are correct that the C++ draft permits for plain ints that are permitted to be wider than 32 bits. To quote:
表面上看来这似乎表明，在我的64位体系结构(以及其他所有人的体系结构)上，普通的int应该具有64位的大小；这是体系结构建议的大小，对吗?但是，我必须断言，即使是64位体系结构，自然的大小也是32位.规范中的报价主要是在需要16位纯整数的情况下出现的.
This would ostensibly seem to say that on my 64 bit architecture (and everyone else's) a plain int should have a 64 bit size; that's a size suggested by the architecture, right? However I must assert that the natural size for even 64 bit architecture is 32 bits. The quote in the specs is mainly there for cases where 16 bit plain ints is desired.
公约是一个强大的因素，从32位纯int的体系结构开始，如果将其源代码保留为32位，那么对于设计人员和他们的用户来说，将其源代码更改为64位体系结构将更加容易.方式:
Convention is a powerful factor, going from a 32 bit architecture with a 32 bit plain int and adapting that source for a 64 bit architecture is simply easier if you keep it 32 bits, both for the designers and their users in two different ways:
首先，每个系统之间的差异越小，每个人的工作就越容易.系统之间的差异对于大多数程序员而言只是头疼的问题:它们只会使跨系统运行代码变得更加困难.它甚至会添加到相对罕见的情况下，在这种情况下，您将无法在32位和64位相同分布的计算机上执行此操作.但是，正如约翰·库格曼(John Kugelman)所指出的那样，架构已经从16位变为32位纯整数，麻烦的今天可以再次进行，这与他的下一个观点有关:
The first is that less differences across systems there are the easier is for everyone. Discrepancies between systems been only headaches for most programmer: they only serve to make it harder to run code across systems. It'll even add on to the relatively rare cases where you're not able to do it across computers with the same distribution just 32 bit and 64 bit. However, as John Kugelman pointed out, architectures have gone from a 16 bit to 32 bit plain int, going through the hassle to do so could be done again today, which ties into his next point:
更重要的部分是它将导致整数尺寸或需要新类型的差距.因为sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)在实际的规格中，所以如果将int移至64位，则会强制使用间隙，因此间隙是不可避免的.它从移位long开始.如果将普通int调整为64位，则sizeof(int) <= sizeof(long)会强制long至少为64位的约束，并且从那里开始在大小上存在固有的差距.由于通常将long或普通int用作32位整数，并且现在都不可用，因此我们只有一个可以使用的另外的数据类型，即short.因为short的最小位数为16位，如果您仅丢弃该大小，则它可能变为32位并填补该空白.但是short旨在针对空间进行优化，因此应 保持这样，并且还有 用例，适用于小的16位整数.无论您如何安排尺寸，都会损失宽度，因此用例无法完全使用int.
The more significant component is the gap it would cause in integer sizes or a new type to be required. Because sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long) is in the actual specification, a gap is forced if int is moved to 64 bits, a gap is simply inevitable. It starts with shifting long. If a plain int is adjusted to 64 bits, the constraint that sizeof(int) <= sizeof(long) would force long to be at least 64 bits and from there there's an intrinsic gap in sizes. Since long or a plain int usually are used as a 32 bit integer and neither of them could now, we only have one more data type that could, short. Because short has a minimum of 16 bits if you simply discard that size it could become 32 bits and fill that gap. However short is intended to be optimized for space so it should be kept like that and there are use cases for small, 16 bit, integers as well. No matter how you arrange the sizes there is a loss of a width and therefore use case for an int entirely unavailable.
这现在意味着需要更改规格，但是即使设计师无赖，很可能会因更改而损坏或过时.持久系统的设计人员必须处理整个系统中相互纠缠的代码，包括他们自己要运行的系统代码，依赖项和用户代码，而这样做的大量工作却不考虑后果，这是不明智的
This now would imply a requirement for the specifications to change, but even if a designer goes rogue, it's highly likely it'd be damaged or grow obsolete from the change. Designers for long lasting systems have to work with an entire base of entwined code, both their own in the system, dependencies, and user's code they'll want to run and a huge amount of work to do so without considering the repercussions is simply unwise.
请注意，如果您的应用程序与> 32位整数不兼容，则可以使用static_assert(sizeof(int) * CHAR_BIT <= 32, "Int wider than 32 bits!");.但是，谁知道规范 可能会发生变化，并且将实现64位纯整数，因此，如果您想作为将来的证明，请不要执行静态断言.
As a side note, if your application is incompatible with a >32 bit integer, you can use static_assert(sizeof(int) * CHAR_BIT <= 32, "Int wider than 32 bits!");. However, who knows maybe the specifications will change and 64 bits plain ints will be implemented, so if you want to be future proof, don't do the static assert.
这篇关于当前是否使用带有int超过32位宽的C ++编译器的系统?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！