ターゲットとしての「標準（32/64-bit Intel）」アーキテクチャは実際には何を意味しますか？

Question

新しい機能を追加したアプリケーションがあります。 これはデバッグモードでテストされましたが、リリース用のコンパイルで多数のエラーが発生しました。

これは、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 10.5に

CGFloat値ではなく値です。 64ビットシステムを構築する場合、または64ビットのように32ビットを構築する場合、NSPointはCGPointにtypedefされます。

"標準（32/64ビットIntel）"アーキテクチャでこれを "64ビットIntel"に変更すると、この問題が解決されました。 NSPointとCGPointの間の明示的な変換を含めることで問題を解決できますが、これは不器用です（64ビットでは不要です）。

「標準（32/64ビットIntel）」アーキテクチャが実際に意味するものを発見しようとしましたが、空白が描かれました。私が見つけることができる唯一のものはこれでした： -

製品が構築されるアーキテクチャのリスト。これは、通常、プラットフォームによって提供される定義済みのビルド設定に設定されます。複数のアーキテクチャが指定されている場合、ユニバーサルバイナリが生成されます。

アプリケーションパッケージ内を巡っても、標準（32/64ビットIntel）と64ビットIntelでは大きな違いはありませんでした。

誰もがこれを知ってもらえますか？10.6以降をターゲットとするアプリケーションで「標準（32/64-bit Intel）」を作成しようとすると何か問題がありますか？

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 10.5に

CGFloat値ではなく値です。 64ビットシステムを構築する場合、または64ビットのように32ビットを構築する場合、NSPointはCGPointにtypedefされます。

正しい。 32ビット用にビルドする場合、NSPointはCに従ってCGPointと互換性がない別の構造ですが、実際には同じ形式で同じ値を保持します。

「32ビットのような64ビット」の部分は、それを可能にするマクロであり、他のいくつかは64ビットのビルドと同じように定義されます。マクロの名前はNS_BUILD_32_LIKE_64です。その機能を有効にするには1に定義してください。私はそれをお勧めします。

"標準（32/64-bit Intel）"アーキテクチャでこれを "64-bit Intel"に変更してコンパイルしていましたが、この問題は解決しました。
NSPointとCGPointの間の明示的な変換を含めることで問題を解決できますが、これは不器用です（64ビットでは不要です）。

これらは他の2つのソリューションです。

「標準（32/64ビットIntel）」アーキテクチャが実際に意味するものを発見しようとしましたが、空白が描画されました。私が見つけることができる唯一のものはこれでした： -

製品が構築されるアーキテクチャのリスト。これは、通常、プラットフォームによって提供される定義済みのビルド設定に設定されます。複数のアーキテクチャが指定されている場合、ユニバーサルバイナリが生成されます。アーキテクチャの定義（ARCHS）その特定の値が、一般的ではない設定だ

。

アプリケーションパッケージでのポスティングは、標準（32/64ビットIntel）と64ビットIntelの間に大きな違いはありませんでした。

誰もがこれを知ってもらえますか？10.6以降をターゲットとするアプリケーションで「標準（32/64-bit Intel）」を作成しようとすると何か問題がありますか？

を含む64ビットのMac OS Xに変更いくつかのこと、：

• いくつかの新しい機能は、このような非脆弱なインスタンス変数として、言語に登場。これにより、実行時にインスタンス変数を追加することができ、より便利には、インスタンス変数宣言をヘッダ内に宣言するのではなく、実装ファイル内に隠すことができます。
• 幾何学的構造の定義が変更されました。これはあなたが遭遇したものです。 CGPointが期待される場合はNSPointを自由に渡すことができ、その逆も同様で、他の構造の場合も同様です。
• 同様に、以前にfloatとしていくつかの点を取ってきた多くのメソッドは、CGFloatとして受け取ります。これは、doubleと定義されます。
• NSUIntegerは、unsigned longと定義され、unsigned intではなく、NSIntegerと同様に定義されます。

これらの一部は、言語の変更などの32ビットOS Xと互換性がありません。単純に32ビット用に構築できないプログラムを書くことは可能です。

その他の破損はより柔らかい。上記のように、いくつかの定義は64ビットで変更されましたが、古い定義は互換性のために32ビットでデフォルトのままですが、前述のマクロで変更することができます。

これはどうしてですか？

2006年後半/ 2007年前に導入されたMacモデルは、32ビットIntelアーキテクチャ（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ビット用に構築する唯一の理由は、5年前のハードウェアをサポートしたいということです（たとえば、それがあなたのものであれば）。新しい言語の機能を使い、5歳のMacを所有している顧客を放棄しても構わない場合は、64ビット版のみを使用して振り返ってはいけません。

これはもちろん、Carbonでサポートされていない関数を使用する手書きのi386アセンブリコードやコードがないと仮定しています。そうした場合、それは32ビットに固執する別の潜在的インセンティブです。 Mac OS Xの32ビットプログラムのサポートは、いつか消え去るかもしれません。有益な回答のため

• 64-bit Transition Guide
• 64-bit Transition Guide for Cocoa