以下是Bjarne Stroustrup的书"C++编程语言"的摘录:
第4.6节:
C++的基本类型的某些方面,例如int的大小,是实现定义的(§C.2).我指出了这些依赖关系,并经常建议避免它们或采取措施尽量减少它们的影响.你为什么要打扰？在各种系统上编程或使用各种编译器的人非常关心,因为如果他们不这样做,他们就不得不浪费时间寻找和修复模糊的错误.声称他们不关心可移植性的人通常会这样做,因为他们只使用一个系统,并且觉得他们能够承担"我的编译器实现的语言"的态度.这是一个狭隘而短视的观点.如果您的程序成功,可能会被移植,因此有人必须找到并修复与实现相关的功能相关的问题.此外,程序通常需要与同一系统的其他编译器一起编译,甚至你喜欢的编译器的未来版本可能会做一些与当前版本不同的东西.在编写程序时,了解并限制实现依赖性的影响要比在之后尝试解决混乱更容易.
限制依赖于实现的语言功能的影响相对容易.
我的问题是:如何限制依赖于实现的语言功能的影响？请提及依赖于实现的语言功能,然后展示如何限制其影响.
几个想法：
不幸的是，您必须使用宏来避免某些特定于平台或特定于编译器的问题。您可以查看 Boost 库的标头，发现它很容易变得麻烦，例如查看文件：
不同平台之间的整数类型往往很混乱，您必须定义自己的 typedef 或使用Boost cstdint.hpp之类的东西
如果您决定使用任何库，请检查给定平台是否支持该库
使用具有良好支持和明确记录的平台支持的库（例如 Boost）
您可以通过严重依赖 Qt 等库来从某些 C++ 实现特定问题中抽象出来，这些库提供了类型和算法意义上的“替代方案”。他们还尝试使 C++ 编码更加可移植。有效吗？我不知道。
并不是所有的事情都可以用宏来完成。您的构建系统必须能够检测平台和某些库的存在。许多人会建议autotools项目配置，另一方面我推荐CMake（相当好的语言，仅此而已M4）
如果您进行一些低级干预（即reinterpret_cast和朋友类似的事情（朋友在 C++ 上下文中是一个坏词）），字节序和对齐可能会成为一个问题。
为编译器添加很多警告标志，对于 gcc 我建议至少-Wall -Wextra. 但还有更多，请参阅编译器的文档或这个问题。
您必须注意所有由实现定义和依赖于实现的内容。如果你想要真相，只想要真相，除了真相什么都没有，那就去ISO标准。