Mat*_*son 17
是的,您应该为函数的参数使用正确的数据类型,否则您可能会遇到麻烦.
而且,这些类型的定义会是这样的,而不是使用的原因int,char等的是它移除了"任何编译器认为的int大小应为"从OS的界面.这是一件非常好的事情,因为如果你使用编译器A,编译器B或编译器C,它们都将使用相同的类型 - 只有库接口头文件需要做正确定义类型的事情.
例如,通过定义非标准类型的类型,可以很容易地int从16位更改为32位.Windows的第一个C/C++编译器使用16位整数.只是在1990年代中后期,Windows获得了32位API,直到那时,你使用的int是16位.想象一下,你有一个运行良好的程序,它使用了几百个int变量,突然之间,你必须将所有这些变量改为其他东西......不是很好,对 - 特别是那些变量中的一些不需要更改,因为为某些代码移动到32位int不会有任何区别,因此更改这些位没有意义.
应该注意的是,WCHAR它不是const char- WCHAR是一个"宽字符",因此wchar_t是可比较的类型.
因此,基本上,"定义我们自己的类型"是一种保证可以更改底层编译器体系结构的方法,而无需更改(大部分)源代码.所有进行机器编码的大型项目都会做这种事情.
Kei*_*son 11
的尺寸和内置的类型,如其它特性int和long可以变化从一个编译器至另外,通常取决于在其上运行代码的系统的基本架构上.
例如,在最初实现Windows的16位系统上,int只有16位.在更现代的系统上,int是32位.
Microsoft可以定义类型,DWORD以便它们的大小在其编译器的不同版本或用于编译Windows代码的其他编译器中保持相同.
这些名称旨在反映微软定义的底层系统的概念.A DWORD是一个"双字"(如果我没记错的话,在Windows上是32位,即使机器"字"在现代系统上可能是32位甚至64位).
使用定义的固定宽度类型可能更好<stdint.h>,例如uint16_t和uint32_t- 但这些只是通过1999 ISO C标准(即使在今天微软的编译器也不完全支持)引入C语言.
如果您正在编写与Win32 API交互的代码,那么您肯定应该使用该API定义的类型.对于不与Win32交互的代码,请使用您喜欢的任何类型,或者您正在使用的接口建议的任何类型.
rod*_*igo 10
我认为这是一次历史性事故.
我的理论是,最初的Windows开发人员知道标准的C类型大小取决于编译器,也就是说,一个编译器可能有16位整数,另一个编译器可能有32位整数.所以他们决定使用一系列typedef在不同的编译器之间移植Window API:DWORD无论你使用什么编译器/架构,都是32位无符号整数.当然,现在您将使用uint32_t从<stdint.h>,但这并不是当时可用.
然后,在UNICODE的情况下,他们得到了TCHARvs. CHARvs. WCHAR问题,但这是另一个故事.
而且,它变得失控,你会得到如此美好的东西typedef void VOID, *PVOID;,完全是胡说八道.