我一直在阅读C++ Primer，因为所有关于 C++11 语言变得多么可用的说法。这本书可能还不错，但它仍然让我每隔几页就想知道代码的真正作用。结果我最终在谷歌上搜索 了很多 很多东西 ......只是最终得到了一些类似“机器特定”或“实现定义”等的东西。
我意识到这意味着什么，以及可移植代码的重要性。
但我确实想知道，“普通”64 位 x86 PC 的这些细节的实际值是多少？由于 GCC、Visual Studio 等实际上并没有询问在所有这些情况下要做什么，而只是编译代码（它可以工作！），似乎有一些针对桌面的合理默认设置。
是否有涵盖这些细节的文档（以非编译器编写者可以理解的方式，例如我链接到的页面）？
大多数 Unix 或 Linux 系统，您可以登录并发出命令
定位limits.h
它会找到一些包含文件，其中列出了编译器使用的值的“限制”。Linux 内核代码中的许多限制文件都是特定于体系结构的，这是您特别感兴趣的
坦率地说，便携性很难达到 100%。我已经编程了 30 年，除了 100% 可移植的简单程序外，我从未见过任何东西。鉴于 PC 无处不在，我认为您不应该关心可移植性而不是功能。因此，您找到的所有引用都是“定义的实现”。
在一个完美的世界里，程序应该是可移植的。在现实世界中，操作系统制造商添加功能以与其他操作系统制造商甚至他们自己竞争（Win 95、98、2000、XP、7、Vista）（和 Linux 发行版存在差异）。因此，便携性——在我的经验中——意味着你不愿意做出权衡：太慢、太笨重、太多的开发时间、太多的测试等等。如果你寻求便携性，你需要问为什么，是否值得。即使您决定这样做，您也会发现自己会根据您的环境添加编译时选项，并且最终可能会得到特定且不可移植的整个文件。
当我为 Atmel Mega16 编写代码时，我不会考虑是否要移植该代码。在这种情况下，您没有无限的 CPU 周期和无限的内存来考虑便携式解决方案——我们正试图从一个小微型中挤出所有的汁液。
同样，您通常需要优化汇编程序中的例程，以便获得更多功能的 CPU 周期。（就像一个运行 DFT 的 DSP——当你第一次发布它时它在 C 中是可以的，但最终你需要将它减少到 ASM 以取回一堆 CPU 周期，以便你的老板希望你在明天早上之前添加另外 23 个功能。该死的便携性。）
所以，是的，很多都是特定于实现的。在 PC 世界中，您拥有更多的奢侈，但如果您正在编写与硬件接口的代码，您通常会被迫创建不可移植的代码。我可以继续讨论这个问题，但我有一个需要优化的循环......