1

このようなカスタムメソッドがある場合：

- (void)myMethod:(id)myArgument 
{
      //do something with myArgument
}

myArgumentは、所有権を取得しない場合、そのメソッドの実行に固執することが保証されていますか？

編集 さらに詳しく説明させてください。これをどこかで呼んでいるとしましょう：

[self myMethod:_myIvar];

そして、どこか別の場所で、myMethodの実行中に、誰かがこれを呼び出します。

[_myIvar release];

それはmyMethod内の引数に影響しますか？

編集終了

ドキュメント/サンプルコードを見ると、カスタムメソッドの上部に[myArgumentretain]または[myArgumentcopy]が表示されることはめったにありません。それで、それは不要ですか？

ありがとう！

4

3 に答える 3

1

myArgumentが開始時に有効なオブジェクトであり、myMethodメソッド中に割り当てを解除したり収集したりするために何もしなかった場合、yesはmyArgumentメソッドの終了時に引き続き有効なオブジェクトになります。

質問の編集に応じて編集する：この場合のオブジェクトの所有権について話しましょう。関数への引数として渡さmyArgumentれた場合、-コンテキストで-ingまたはingmyMethodによってオブジェクトへの関心を宣言しないでください。このような状況では、オブジェクトの所有者のみが外部に存在します。retaincopymyMethod

の最後の所有者がそれが完了したとmyArgument判断し、それを実行した場合、それがなくなる可能性は完全にあります。オブジェクトを維持するための強力な参照はもうありません。スレッドの懸念、関連する自動解放プール、およびその他の多くの問題によっては有効な場合がありますが、これは危険なゲームです。そのような状況が発生する可能性さえある場合は、メモリ管理ポリシーで推奨されているように、内で明示的に関心を表明する必要があります。myArgumentreleasemyArgumentmyArgumentmyMethod

于 2012-11-02T16:53:01.557 に答える
0

別のスレッドによってmyArgumentによって参照されるオブジェクトの割り当てが解除される可能性がある場合でも、myArgumentはいつでもジャンクメモリへのポインタになる可能性があり、クラッシュします。

これは、 -myMethodに保持しないこととは関係ありません。同じように、retainメソッドの呼び出し中にクラッシュする可能性があります。むしろ、修正しなければならない壊れた、実行不可能なスレッドモデル/アーキテクチャがアプリにあります。

これがスレッド化が難しい理由です。

于 2012-11-02T17:13:45.043 に答える
-1

いいえ、保証されていません。retain保持したいものは何でも、終了したら呼び出す必要がありますrelease。それ以外の場合は、別のスレッドを使用して、その間に割り当てを解除します。

ゲームのA*アルゴリズムを作成するときに、私はそれを噛みました。

于 2012-11-02T17:07:28.197 に答える