为什么每个人都使用标准的Ctypes进行input？
如果你想使用Qt ，你必须拥抱quint8 ， quint16等等。
如果你想使用guint8 ，你必须欢迎guint8 ， guint16等等。
在Linux上有u32 ， s16等等。
uC / OS定义SINT32 ， UINT16等等。
如果你必须使用这些东西的组合，你最好准备好麻烦。 因为在你的机器上， quint32会被long typedef ，并且quint32将会被int ，编译器会报错 。
为什么每个人都这样做，如果有<stdint.h> ？ 这是图书馆的某种传统吗？
当这些库被开发时， stdint.h不存在。 所以每个库都有自己的typedef 。
对于较旧的库，这是需要的，因为问题头（ stdint.h ）不存在。
但是，仍然存在一个问题：这些types（ uint64_t和其他）是标准中的可选function 。 因此，一个合规的实现可能不会与他们一起发布 – 从而迫使图书馆现在仍然包括他们。
自1999年以来， stdint.h已经被标准化了。许多应用程序更有可能定义（有效别名）types，以保持与底层机器体系结构的部分独立性。
它们为开发人员提供了信心，即在其应用程序中使用的types与项目特定的行为假设相匹配，这些假设可能不符合语言标准或编译器实现。
这种做法被反映在面向对象的Facadedevise模式中，并且被开发人员滥用，这些开发人员总是为所有导入的库编写包装类。
当编译器的标准要低得多时，机器结构可以从16位， 18位到36位字长的主机变化，这更多的是考虑因素。 现在，在32位ARMembedded式系统的世界里，这种做法就没那么重要了。 奇数内存映射的低端微控制器仍然是一个问题。
所以你有权力将intdef chartypes化。
一个“编码恐怖”提到，一家公司的头文件有一个程序员想要一个布尔值的地方，而char是作业的逻辑本机types，所以写了typedef bool char 。 后来有人发现一个整数是最合理的select，并写了typedef bool int 。 在Unicode之前的结果，实际上是typedef char int 。
相当多的前瞻性，向前兼容性，我认为。
