从其它平台迁移而来
起因
以前使用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
的。
呃~这一下就扯到编译器上了,完全是咱的知识盲区嘛!既然大佬都这么说了,而且也这么多年了,肯定是不会错的,那么,就当是长了次见识了吧!