0

分散オブジェクトを提供している ARC を使用する 64 ビット アプリケーションがあります。プロキシ オブジェクトを使用するアプリケーションは 32 ビット アプリケーションであるため、ARC を使用していません。これは私に問題を引き起こしますか？

また、32 ビット アプリケーション内で、64 ビット/ARC アプリケーションのクラスを再利用したいと考えています。それらが ARC の場合、ARC 以外のアプリケーションにどのように統合できますか?

4

1 に答える 1

1

これを行うことはお勧めしません。32 ビットと 64 ビットのランタイム間で分散オブジェクトを使用することは可能であるように見えますが、いくつかの問題があります。財団定数リファレンスから：

Mac OS X v10.5 より前では、NSNotFound は 0x7fffffff として定義されていました。32 ビット システムの場合、これは実質的に NSIntegerMax と同じでした。64 ビット環境をサポートするために、NSNotFound は正式に NSIntegerMax として定義されるようになりました。ただし、これは、32 ビット環境と 64 ビット環境では値が異なることを意味します。したがって、値をファイルまたはアーカイブに直接保存しないでください。さらに、分散オブジェクトを介して 32 ビット プロセスと 64 ビット プロセス間で値を送信しても、反対側では NSNotFound が取得されません。これは、分散オブジェクトを介して呼び出され、NSArray の indexOfObject: メソッドなど、NSNotFound を返す可能性があるすべての Cocoa メソッドに適用されます (配列のプロキシに送信された場合)。

確かに、-[NSArray indexOfObject:] に対していくつかの基本的なサニティ チェックを実行できますが、使用しているライブラリまたはフレームワーク (Cocoa と Foundation を含む) が NSNotFound を返す可能性のある API を使用している場合はどうなるでしょうか? 言うまでもなく、これは 32 ビットと 64 ビットのランタイム間の通信で発生する唯一の問題であり、他の問題は文書化されていない可能性があります。

私は、分散オブジェクトには他のいくつかの問題があるため、敬遠する傾向がありますが、それらを使用することに決めていたとしても、これは契約違反のように思えます。

ARC と分散オブジェクトを一緒に使用することを妨げるような ARC 固有の要素があるとは思いません。ただし、分散オブジェクトのメモリ管理には注意が必要です。クライアントとサーバー間のメモリ リークを回避するために、標準の保持と解放の規則を破る必要がある場合、ARC ではそれができませんでした。これを回避するには、サーバーの設計に細心の注意を払う必要があります。

最後に、32 ビット ランタイムでは ARC を使用できないため、これらのクラスの保持/解放コードを手動で記述する必要があります。最終的に非 ARC コードから離れることを計画している場合は、__has_feature(objc_arc)を利用できます。それ以外の場合は、32 ビット アプリケーションと 64 ビット アプリケーションの間で共有する予定のファイルに対して ARC を使用しない方がよいでしょう。ARC は、ファイルごとに有効または無効にできます。

于 2012-05-16T04:46:14.623 に答える