什么是＆＃34;标准（32/64位英特尔）＆＃34;架构作为目标实际上是什

时间：2011-12-03 23:36:55

标签： cocoa xcode3.2

我有一个应用程序，我添加了一些新功能。 这是在调试模式下测试的，但是在为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位英特尔）”是否有任何意义？

1 个答案:

答案 0 :(得分：6)

  

一些侦探工作表明，这些是由在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是一个单独的结构，根据C与CGPoint不兼容，尽管它们确实以相同的格式保存相同的值。

“构建32位像64位”部分是一个可以定义的宏，可以使其与其他一些内容的定义方式与64位版本相同。宏的名称是NS_BUILD_32_LIKE_64;将其定义为1以启用该功能。我推荐它。

  

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

烨。这是另外两种解决方案。

  

我试图发现“标准（32/64位英特尔）”架构实际意味着什么，但画了一个空白。我唯一能找到的是： -

     
    

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

  

这通常是架构（ARCHS）设置的定义，而不是特定值。

  

在应用程序包中进行探讨似乎没有显示标准（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，a.k.a。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有相关文档：

相关问题
最新问题