我是.net开发人员。我用于数据类型，如：字符，字符串，布尔值，整数，长整数和小数。
我在c ++工作了很多年，在业余时间学习了windows api。
windows api有更多的数据类型，我现在明白了这个的原因。但是，如果您想使用32位数据类型，那么您可以使用任何32位数据类型，还是仅限于满足您特定要求的32位数据类型？
答案 0 :(得分：0)
在编译器的“底部”，只有少量的实际数据类型 - 它稍微依赖于实际的编译器实现如何描述，但例如LLVM已经
i1代表bool i8代表char i16代表short i32代表int（有时候是long）i64代表long long（有时候是long）LLVM编译器也将指针理解为单独的东西。
有符号和无符号类型仅在执行某些操作时相关，因此在基础层，编译器不区分它们，除非它在何时执行操作 - 主要是小于/大于受签名/未签名的影响。
你选择哪一个？这真的取决于。您是否希望始终保证大小（适用于文件格式，协议和API功能） - 如果是这样，请使用来自#include <cstdint>的uint32_t或int32_t。如果你只是想要“大于短”的东西，那么使用int（假设我们知道我们永远不会在具有16位整数的系统上编译它！） - int是定义为“机器自然的类型，并且会很快”，这不能保证是int32_t的情况（在所有现有的Windows平台上它都是一样的，但它不一定是未来和/或其他平台上的案例）
如果您希望代码是可移植的，那么执行您自己的typedef可能是有意义的，例如：
typedef uint32_t count_type;
这样，如果您需要更改该类型，您只需要在一个地方更改它。
Windows有自己的定义，很大程度上是因为当时没有定义任何严格的类型，所以他们必须自己构成 - 当然，一旦你为类型引入了一个名字，它就会破坏如果你删除那个名字就会有很多代码，只是因为有另一个名字可以做同样的事情 - 同时，标准需要新的类型，所以它们也被定义了。
答案 1 :(得分：0)
现在有更多关于windows api和i的数据类型 了解原因。
是哪个？
对于大多数编程任务，Windows API中的数据类型通常只会使事情变得复杂并且什么都不会获得。它们不是其他类型而是typedef s，即相同（基本）类型的不同名称。这不是类型安全的。例如，UINT32是unsigned int的typedef。这意味着以下工作：
void f(UINT32 x);
// ...
unsigned int i;
f(i); // no compiler error even though you used the "wrong" type
但是，如果您想使用32位数据类型，那么您可以使用 任何32位数据类型或限制为32位数据类型 哪些符合您的具体要求？
首先，您应该问自己，精确使用32位的要求是否只是一种人为的要求。我之所以提到这一点，是因为人们经常会对所谓的性能提升提出这样的要求，或者因为他们想要“更接近”机器并且不相信他们的编译器和环境来生成最佳二进制文件;两者都是非常值得怀疑的假设。
C ++中的规则是，如果你没有充分的理由这样做，只需使用int作为数字。
要考虑的第二件事是你是否要求类型至少 32位。如果是这样，C ++标准会产生几个guarantees about minimum widths。如您所见，unsigned long是一个保证至少有32位的类型的示例。
如果您需要完全固定的宽度，请考虑new C++11 data types。
在任何情况下，如果您实际执行位操作，则使用无符号类型。这是上面提到的“好理由”之一。由于其破坏的整数算术，应该避免使用无符号的任何其他东西，但就原始类型而言，它是位操作的最佳选择。最后，由于您使用的是C ++，为什么不使用std::bitset？它是一种更高级的位操作构造，可以大大加快您的工作速度并提高代码的稳健性。