为何众多库要自行定义固定宽度整数，而非使用C++标准提供的对应类型？

至少从C11开始，标准库已经提供了开箱即用的固定宽度整数类型，比如C的<cstdint>或C的<stdint.h>中定义的std::uint32_t、std::int8_t等类型，还有INT16_C、UINT32_C这类最小宽度宏定义，但目前依然有大量库在使用自定义的固定宽度整数类型，背后主要有这些原因：

• 历史遗留兼容：绝大多数有自定义整数类型的库诞生时间远早于C11标准，甚至早于C99标准。在C99引入<stdint.h>、C11引入<cstdint>之前，C++标准完全没有官方的固定宽度整数定义，各编译器实现的基础整数长度也不统一，库必须自己封装uint32_t这类类型才能保证跨平台的宽度一致。后续标准普及后，库为了不破坏已有的海量旧项目代码兼容性，不可能删除沿用多年的自定义类型定义。
• 极端场景适配：即使是C++11普及之后，很多面向嵌入式、小众平台的库依然会遇到工具链不支持标准<cstdint>，或是标准定义存在缺陷的情况。库自己封装一层固定宽度整数后，只需要在对应平台的配置头文件中修改typedef的指向，不需要改动全库所有用到整数的业务代码，适配成本极低。
• 接口稳定性与风格统一：很多库有统一的命名规范，比如Qt的quint32、SFML的sf::Int32都和库自身的命名风格一致，降低用户的学习成本。更重要的是，自定义类型作为库对外公开的接口，后续如果需要调整底层实现，只要保证对外的宽度、符号属性不变，就不会破坏现有用户代码的ABI兼容性，也不需要用户修改任何调用逻辑。
• 扩展功能支持：部分库的自定义固定宽度整数并非简单的typedef，还会绑定库自身的其他能力，比如和序列化、反射、类型检查框架适配，这些都是标准std::uint32_t这类基础类型无法直接实现的，单独封装一层可以实现更多扩展能力。

你提到的类型冲突问题确实是这类自定义类型的常见副作用，目前多数维护活跃的库都会保证自己的自定义固定宽度整数和同宽度的标准类型内存布局、取值范围完全一致，遇到类型不匹配的场景时，用static_cast转换即可，不会引入运行时风险。近年来的新C库如果不需要兼容C11之前的环境，大多已经直接使用标准库的固定宽度整数，减少这类冲突问题。

内容的提问来源于stack exchange，提问作者nada