至少從 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固定寬度整數傳遞給庫中的函式時，該函式期望具有完全相同的寬度但定義不同的固定寬度整數。
固定寬度整數的要點是它們具有固定的大小，正如您所知，這是我們在許多情況下所需要的。那么，為什么所有這些庫都會使用我們在 C 標準中已經擁有的完全相同的整數進行 typedef 呢？這些額外的定義有時會令人困惑、多余，并且可能會侵入您的代碼庫，這是非常糟糕的事情。如果他們沒有他們承諾的寬度和簽名，他們至少違反了最少驚訝的原則，所以我在此問你他們的意義是什么？
uj5u.com熱心網友回復：
為什么這么多庫定義自己的固定寬度整數？
大概有以下幾個原因：
它們在 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 中），以可能使用GMPlib支持任意精度算術（或 bignums）。他們希望以某種方式通過Frama-C或DO-178C認證（對于嵌入式關鍵軟體系統）進行證明
它們是特定于處理器的（例如asmjit，它在運行時在一些架構上生成機器代碼）
它們可能與特定的硬體或編程語言（Tensorflow、OpenCL、Cuda）介面。
他們希望可以從Python或GNU guile 中使用。
它們可能是特定于作業系統的。
他們添加了一些額外的運行時檢查，例如針對除以 0（或其他未定義的行為）或溢位（C 標準不能要求，出于性能或歷史原因）
它們旨在從機器生成的C 代碼（例如RefPerSys、ANTLR等）中輕松使用
它們被設計為可從 C 代碼呼叫（例如libgccjit）。
等等......尋找其他好的理由留給讀者作為練習。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/364608.html