delphi – 为什么PDWord不^ DWORD?
这个程序
{$APPTYPE CONSOLE} {$TYPEDADDRESS ON} uses Winapi.Windows; procedure Foo(P: PDWORD); begin end; procedure Bar; var dw: DWORD; begin Foo(@dw); end; begin end. 在XE3中编译,但在XE4,XE5,XE6和XE7中不编译。错误是 Foo(@dw); [dcc32 Error] E2010 Incompatible types: 'PDWORD' and 'Pointer' 这感觉奇怪。所以,在一点挖掘后,似乎问题是由PDWORD的定义。人们可能自然地认为: PDWORD = ^DWORD; 实际上是XE3的情况。在更高版本中,我们发现: // Note: Not ^DWORD yet PDWORD = ^CppULongInt; 奇。那么,什么是CppULongInt? CppULongInt = type LongWord; {$EXTERNALSYM CppULongInt 'unsigned long'} {$OBJTYPENAME CppULongInt 'Bul' 'Gm'} 然后看看DWORD的声明,我们发现: //NOTE: DWORD should really be CppULongInt DWORD = LongWord; 所以,CppULongInt和DWORD是不同的类型。因此编译错误。 这里发生了什么? CppULongInt的目的是什么?为什么RTL设计者似乎想要将DWORD别名为CppULongInt。此更改是否与基于LLVM的x64 Windows C编译器相关?我是世界上唯一使用{$ TYPEDADDRESS ON}的人吗? 注意,最后一个问题是修辞。 解决方法
它看起来有人在Embarcadero没有阅读相关的Windows文档:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx DWORD被显式定义为32位无符号整数,因此在Delphi中它应该是一个UInt32。 它是DWORD_PTR(这不是一个PDWORD!)被定义为ULONG_PTR,后者根据平台 – Win32或Win64 – 而不是un unsigned long的编译器定义改变大小。 一个原因可能是他们正在尝试在非Windows平台上使用DWORD和其他Windows数据类型,并试图保持它们兼容。如果是这样,在这种情况下,他们失败,并引入了一个错误,因为使用的定义将无法在Windows中正常工作。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |