NSCopyingを実装しているときにゾーンが常にnilであるのはなぜですか？

それは簡単な質問かもしれないが、私のクラスでNSCopyingプロトコルを実装し、なぜ、私はこれはオブジェクトとコピー配列のために、このメソッドを使用して呼び出されたゼロNSCopyingを実装しているときにゾーンが常にnilであるのはなぜですか？

- (id)copyWithZone:(NSZone *)zone 
{ 
    if (zone == nil) 
     NSLog(@"why this is allways nil"); 

    (...) 
}

ゾーン==を取得します。

[[NSArray alloc] initWithArray:myArray copyItems:YES]];

出典

2011-10-28 Marcin

ケビンさんとロビンの答えが最も正確である参照してください。オスカーの答えは正しいものです。しかし、Gnustepのドキュメントもlogancautrellのゾーンの存在理由も、まったく正しいものではありません。最初NXZone、NSZone - -

ゾーン最初に作成された多くが真であることを、単一ゾーンから割り当てられたオブジェクトは、メモリ内に比較的連続であろうことを保証します。判明したように、これはアプリケーションが使用するメモリの量を減らしません。それはほとんどの場合、わずかに増加することになります。

大きな目的は、大量のオブジェクトのセットを破壊することができることでした。例えば

ドキュメントを閉じたときに、ドキュメントベースのアプリケーション、オブジェクトグラフのティアダウンに複雑な文書をロードした場合、実際には非常に大きく、高価である可能性があります。ドキュメントのすべてのオブジェクトが単一のゾーンとから割り当てられた場合

従って、そのゾーンの割り当てメタデータがそのゾーンにもした後、文書に関連するすべてのオブジェクトの破壊のように安価であろう単にゾーン破壊（本当に安かった - 「ここで、システム、バックこれらのページを持っている」 - 1つの関数呼び出し）。

これは実行不可能であることが判明しました。ゾーン内のオブジェクトへの単一の参照がゾーン外に漏れた場合、アプリケーションはドキュメントが閉じられるとすぐにBOOMになり、オブジェクトがそれを参照していたことを止める方法はありません。第二に、このモデルは、GCシステムで頻繁に遭遇する「希少資源」の問題に遭遇しました。すなわち、文書のオブジェクトグラフが非メモリリソース上に保持されている場合、ゾーン破壊の前に前記リソースを効率的にクリーンアップする方法がなかった。

結局のところ、パフォーマンスの勝利ではない（複雑なドキュメントをどれくらいの頻度で閉じているか）と、脆弱性が増したことの組み合わせは、ゾーンを悪い考えにしました。 APIを変更するには遅すぎますが、私たちは残っています。

出典

2011-10-28 22:05:43 bbum

恐ろしく、私はあなたがこれに答えることを望んでいた。サイドノートは、これはAppleのドキュメントにいつでも書かれていましたか？今日私が見つけることができるのは、NSZone *の基礎的な方法です。 – logancautrell

あなたが私の注意を引いてくれるような疑問があれば、Twitterで私を尋ねてください。言語（そしてOS）の進化は、本当に魅力的です。これまでに文書化されていた場合、おそらくラプソディの時代に残ったものだったでしょう。私はゾーンが適切なMac OS Xのリリースで推奨されたとは思わない。 – bbum

あなたの投稿は、あなたのユニークな地位と歴史のために高く評価されています。 Appleのエンジニアがもっと多くの時間を費やして欲しいです！ – logancautrell