objective-c - 10.5+ 用に作成する場合、Objective-C ガベージ コレクションを使用する必要がありますか?

Question

OS X 10.5 以降の環境でかなり一般的な Mac コードを作成する場合、ガベージ コレクションを使用することの欠点は何ですか?

これまでのところ、私が書いたものはすべて 10.4 と互換性があるか、iPhone 上にあるので、retain/release にかなり慣れてきましたが、今は 10.5 のみのより大きなプロジェクトに取り組んでいるので、先に進み、Objective-C 2.0 ガベージ コレクターを使用することの欠点です。

皆さんはどう思いますか？

Answer 1

新しいCocoaコードを記述し、Mac OS X 10.5をターゲットにしている場合は、Objective-Cガベージコレクションを使用してください。

iPhoneでも実行する必要のあるコードを記述している場合は、そのコードを別のフレームワークに保持し、プロパティ-retainと-release使用法を使用して記述し、フレームワークとそのユニットテストターゲットは、 GCのみではなくGCでサポートされます。

Xcodeはユニットテストバンドルを2回実行します。1回はGCをオンにし、もう1回はGCをオフにします。フレームワークは、両方の実行モデルで使用できます。その後、最終的にそのモデルレベルのコードをiPhoneに持ち込みたい場合は、iPhoneをターゲットにした静的ライブラリに配置するか、iPhoneプロジェクトに直接含めることができます。

ただし、iPhoneでコードを実行することを検討しているかどうかに関係なく、アプリケーションでLeopardが必要な場合は、ガベージコレクションを確実にターゲットにする必要があります。それは開発を容易にし、Objective-Cガベージコレクターは非常にうまく機能します。

Answer 2

私は自分でメモリ管理を処理することを好みます。それは、そのレベルの制御が好きだからです。他の言語（C＃）での経験から、GCではメモリの問題を完全に無視できないことがわかっています。これはCocoaでも同じで、オブジェクトが明示的に所有されていない場合に（void *）を使用した弱い参照やコールバックなどがあります。別のオブジェクトによって。基本的に、あるセットの課題（メモリリーク）を別のセットと交換しています。個人的には、最近はメモリ管理のミスをあまり多くしない傾向があり、私が犯したものは非常に簡単に追跡できます。

いくつかの状況（アウトラインビューに提供されているオブジェクトを保持したくないNSOutlineViewのデータソースメソッドの実装など）では、GCが本当に役立つと思いましたが、何もしていません。まだそれで実際のテスト。

Appleは、 GCプログラミングガイドに他のいくつかの長所と短所を記載しています。

Answer 3

アプリケーションを iPhone に移植できる可能性がある場合は、使用しないでください。

特別なユース ケースがある場合、ガベージ コレクションはパフォーマンスに悪影響を与える可能性があります。GC がなければ、GC の世界とは異なり、オブジェクトの破壊を正確に制御できます。ほとんどのプロジェクトでは、エラーが発生しにくく簡単な GC を有効にする価値があります。

理論的には、GC を使用しないメモリ管理は常に GC を使用する場合よりも高速ですが、ほとんどの実用的なアプリケーションではそうではありません (GC は通常、人間よりも最適化されているため)。

Answer 4

GC は 10.8 以降では非推奨です。パフォーマンスと安定性の目標が達成されなかったため、チアリーディングは別として、このテクノロジーを採用することは実際には決して良い考えではありませんでした.

管理コードの大部分を除外できるため、メモリを「手動で」管理することは実際には非常に簡単です。私のコード ベースには、メモリ管理に関連するコードが 1% 未満で、必要以上に大きくなっています。したがって、私は ARC についても懐疑的です。それは、ARC が解決しようとしている問題が非常に小さいため、このテクノロジにかなり小さな落とし穴があったとしても、ARC を使用する価値がないからです。