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

Question

至少从 C++11 开始，我们得到了可爱的固定宽度整数，例如在 C++ 的 <cstdint> 或 C 的 <stdint.h> 中开箱即用（例如 std::uint32_t、std::int8_t），所以有或没有std:: 在它们前面，甚至作为最小宽度的宏（INT16_C、UINT32_C 等等）。

然而，我们每天都在处理库，它们定义了它们自己的固定宽度整数，您可能已经看到例如sf::Int32、quint32、boost::uint32_t、Ogre::uint32、ImS32，...如果你愿意，我可以继续说下去。你可能也认识几个。

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

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

Answer 1

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

可能出于以下一些原因：

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

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

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

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

• 他们想成为 cross-compilable 到廉价的嵌入式 microcontrollers，其编译器不是完整的 C++11 编译器。

• 他们可能有通用代码（或template-s，例如Eigen 或Dlib）可能支持arbitrary-precision arithmetic（或bignums）或使用GMPlib。

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

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

• 它们可能与特定硬件或编程语言（Tensorflow、OpenCL、Cuda）交互。

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

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

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

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

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

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