为什么这么多库定义自己的固定宽度整数？

Question

至少从 C++11 开始，我们就得到了可爱的固定宽度整数，例如在 C++<cstdint>或<stdint.h>开箱即用的 C 中（例如std::uint32_t, ），因此无论 前面std::int8_t有或没有，甚至作为最小宽度的宏（ 、和很快）。std::INT16_CUINT32_C

然而，我们每天都会与库打交道，它们定义了自己的固定宽度整数，您可能已经看到过，例如，，，，，，sf::Int32……quint32如果boost::uint32_t您愿意，我可以继续说下去。你可能也认识几个。Ogre::uint32ImS32

有时，这些 typedef（通常也是宏定义）可能会导致冲突，例如，当您想要将std固定宽度整数传递给库中的函数时，期望宽度完全相同但定义不同的固定宽度整数。

固定宽度整数的要点是它们具有固定的大小，正如您所知，这正是我们在许多情况下所需要的。那么为什么所有这些库都会使用和 typedef 与我们在 C++ 标准中已有的整数完全相同的整数呢？这些额外的定义有时会令人困惑、多余，并且可能会侵入您的代码库，这是非常糟糕的事情。如果他们没有承诺拥有的宽度和符号，他们至少违反了最少惊讶的原则，所以我特此问你他们的观点是什么？

Answer 1

为什么这么多库定义自己的固定宽度整数？

大概有以下一些原因：

• 它们在 C++11 或 C11 之前开始（例如：GTK、Qt 、 GCC内部库、Boost、FLTK、GTKmm、Jsoncpp、Eigen、Dlib、OpenCV、Wt）

• 他们希望在自己的namespace内部拥有可读的代码class（拥有自己的命名空间，就像 Qt 那样，可以提高编写良好的代码的可读性）。

• 它们是构建时可配置的（例如使用GNU autoconf）。

• 他们希望能够与旧的 C++ 编译器（例如某些 C++03 编译器）进行编译

• 他们希望能够交叉编译到廉价的嵌入式微控制器，其编译器不是完整的 C++11 编译器。

• 它们可能具有通用代码（或template-s，例如在 Eigen或Dlib中），以支持任意精度算术（或 bignums），可能使用GMPlib。

• 他们希望以某种方式通过Frama-C或DO-178C认证（针对嵌入式关键软件系统）进行证明

• 它们是特定于处理器的（例如，asmjit在某些架构上运行时生成机器代码）

• 它们可能连接到特定的硬件或编程语言（Tensorflow、OpenCL、Cuda）。

• 他们希望可以从Python或GNU guile中使用。

• 它们可能是特定于操作系统的。

• 它们添加了一些额外的运行时检查，例如针对除以 0（或其他未定义的行为）或溢出（出于性能或历史原因，C++ 标准不能要求）

• 它们旨在可以轻松地从机器生成的C++ 代码中使用（例如RefPerSys、ANTLR等）

• 它们被设计为可从 C 代码调用（例如libgccjit）。

• 等等……寻找其他好的理由留给读者作为练习。