"标准(32/64位英特尔)"架构作为目标实际上意味着什么？

Question

我有一个应用程序,我添加了一些新的功能.这是在调试模式下测试的,但是在为Release编译时引入了许多错误.

一些侦探工作显示这些是由调用转换NSView类和CALayer类之间的点引起的,例如

- (NSPoint)convertPoint:(NSPoint)aPoint fromView:(NSView *)aView
- (CGPoint)convertPoint:(CGPoint)aPoint toLayer:(CALayer *)layer
error: incompatible type for argument 1 of 'convertPoint:toLayer:'

试图纠正这个问题导致另一组错误交换,我在NSPoint中发现了问题: -

在Mac OS X v10.5之前,坐标由浮点值而不是CGFloat值表示.在为64位系统构建或构建32位(如64位)时,NSPoint会对CGPoint进行类型化.

我一直在编译默认的"标准(32/64位英特尔)"架构,将其更改为"64位英特尔"解决了这个问题.我可以通过在NSPoint和CGPoint之间包含显式转换来解决问题,尽管这很笨拙(在64位中是不必要的).

我试图发现"标准(32/64位英特尔)"架构实际意味着什么,但画了一个空白.我唯一能找到的是: -

将为其构建产品的体系结构列表.这通常设置为平台提供的预定义构建设置.如果指定了多个体系结构,则将生成通用二进制文件.

在应用程序包中进行探讨似乎没有显示标准(32/64位英特尔)和64位英特尔之间的差异.

任何人都可以对此有所了解,并且在针对10.6或更高版本的应用程序中尝试生成"标准版(32/64位英特尔)"是否有任何意义？

Answer 1

一些侦探工作显示这些是由调用转换NSView类和CALayer类之间的点引起的,例如

- (NSPoint)convertPoint:(NSPoint)aPoint fromView:(NSView *)aView
- (CGPoint)convertPoint:(CGPoint)aPoint toLayer:(CALayer *)layer
error: incompatible type for argument 1 of 'convertPoint:toLayer:'

试图纠正这个问题导致另一组错误交换,我在NSPoint中发现了问题: -

在Mac OS X v10.5之前,坐标由浮点值而不是CGFloat值表示.在为64位系统构建或构建32位(如64位)时,NSPoint会对CGPoint进行类型化.

正确.在构建32位时,NSPoint是一个与CGPointC 不兼容的独立结构,尽管它们确实以相同的格式保存相同的值.

"构建32位像64位"部分是一个宏,你可以定义,使得它和其他一些事情的定义方式与64位版本相同.宏的名字是NS_BUILD_32_LIKE_64; 定义它以1打开该功能.我推荐它.

我一直在编译默认的"标准(32/64位英特尔)"架构,将其更改为"64位英特尔"解决了这个问题.
我可以通过在NSPoint和CGPoint之间包含显式转换来解决问题,尽管这很笨拙(在64位中是不必要的).

对.这是另外两种解决方案.

我试图发现"标准(32/64位英特尔)"架构实际意味着什么,但画了一个空白.我唯一能找到的是: -

将为其构建产品的体系结构列表.这通常设置为平台提供的预定义构建设置.如果指定了多个体系结构,则将生成通用二进制文件.

这ARCHS通常是Architectures()设置的定义,而不是特定值.

在应用程序包中进行探讨似乎没有显示标准(32/64位英特尔)和64位英特尔之间的差异.

任何人都可以对此有所了解,并且在针对10.6或更高版本的应用程序中尝试生成"标准版(32/64位英特尔)"是否有任何意义？

64位Mac OS X中有一些变化,包括:

• 语言中出现了一些新功能,例如非脆弱的实例变量.这允许您在运行时添加实例变量,更有用的是,在实现文件中隐藏实例变量声明,而不是在标头中公开它们.
• 几何结构的定义发生了变化.这就是你遇到的.现在,您可以自由通过的NSPoint,其中一个CGPoint是预期,反之亦然,与同为其他结构.
• 类似地,许多先前采用或返回多个点的方法float现在采用或返回它CGFloat,可以定义为double.
• NSUInteger被定义为unsigned long,而不是unsigned int,同样如此NSInteger.

其中一些是完全不兼容的32位OS X,如语言的变化; 有可能编写一个你根本无法为32位构建的程序.

其他破损更柔软.如上所述,某些定义在64位中更改,但较旧的定义在32位中仍然是兼容性的默认值,但您可以使用上述宏切换它们.

那为什么这很重要？

2006年末/ 2007年初推出的Mac机型仅支持32位英特尔架构(IA32,又称i386).2007年初,Apple开始推出支持64位架构(x86-64)的Mac.

在64位硬件上运行的Mac OS X(到目前为止)总是可以运行32位软件,但在32位硬件上运行的Mac OS X 只能运行32位软件.Mac OS X本身就是为Lion而建的; 现在,它需要64位Mac.

因此,构建32位的唯一原因是您希望支持具有五年历史的硬件(例如,如果这就是您所拥有的).如果您更愿意使用较新的语言功能并且不介意放弃拥有五年历史的Mac的客户,那么请只使用64位而不要回头看.

当然,这是假设您没有任何手写的i386汇编代码或在Carbon中使用不再支持的函数的代码.如果你这样做,那么这是坚持32位的另一个潜在动机.请注意,有一天Mac OS X中对32位程序的支持可能会消失.

Apple有相关文档:

• 64位过渡指南
• 可可的64位过渡指南