从其它平台迁移而来
起因
以前使用Delphi调用海康SDK时,专门改写过HCNetSDK.h,当时大部分桌面应用还都是32位的,毕竟64位还没彻底普及开(即便现在,还是有一部分桌面考虑兼容性依然是32位)。后来也搞过64位版的,编译没问题,运行就不成功。虽然没成功,但心里还是清楚这基本上是数据类型的问题,由于对64位了解不多,也就一直搁置着。
转Lazarus之后,又搞过一次64位版,还是没成功。后来知道有ctypes这个单元,也知道这是专门针对c语言数据类型的,但一直没去看过。近来又想起这个事,就想一探究竟。
探
直接看源码,其实就是给pascal的数据类型取了个c的别名。要想了解透彻,自已撸码跑一下还是很有必要的:
|
|
做为对比,c的也来一下:
|
|
分别用32位和64位编译运行,然后,然后就凌乱了~
|
|
cbool的差异大概知道是怎么回事,这clongdouble是个什么鬼?难道是bug?
先说cbool,在win平台上,使用c的bool类型的很少,大多数都是用微软的BOOL,而32位平台上的BOOL确实是4B,64位的没研究过,想来为了可移植性应该也是4B。
再说clongdouble,从感官上讲,64位类型比32位要大才是正常的,而Lazarus的clongdouble,64位比32位还小,似乎是有问题的。
深深地怀疑这是个bug,然后提了Issues。大概一个小时后,大佬maynard philbrook回复了:
From what I know, and that isn’t much. the Fpc 64-bit compiler does not use the Extended float type because it doesn’t use the FPU, just the 64-bit registers that exist to performs the double math.
From what I understand it was decided that way because function API calls in the OS do it this way so local support for FPU isn’t there.
But is used in the 32-bit target.
Good luck and have a good day.
大意是说:fpc的64位编译器不使用扩展浮点类型,因为它不使用FPU浮点处理单元,只使用用于执行双精度数学运算的64位寄存器,这也是出于考虑到操作系统的API是这么调用的。但是32位的编译器还是使用FPU的。
呃~这一下就扯到编译器上了,完全是咱的知识盲区嘛!既然大佬都这么说了,而且也这么多年了,肯定是不会错的,那么,就当是长了次见识了吧!