#define TT_RELEASE_SAFELY(__POINTER) { [__POINTER release]; __POINTER = nil; }
three20 が ivar を解放した後に nil を代入しても安全だと考えるのはなぜですか? ステップを外すのは危険ivar = nil
ですか?
これは私が見つけたすべてです :
KVO/KVC を使用しているとは思いませんが、よくわかりません。私は今それを読んでいます。
ありがとう!
マット
#define TT_RELEASE_SAFELY(__POINTER) { [__POINTER release]; __POINTER = nil; }
three20 が ivar を解放した後に nil を代入しても安全だと考えるのはなぜですか? ステップを外すのは危険ivar = nil
ですか?
これは私が見つけたすべてです :
KVO/KVC を使用しているとは思いませんが、よくわかりません。私は今それを読んでいます。
ありがとう!
マット
内部にいるとき-dealloc
、この質問は Objective-C の達人を分割します。たとえば、この最近のブログ エントリを読んでください。
他のメソッドの実装内では、そもそもリリース後に変数をスコープ内に保持するべきではないというのが私の個人的な意見です。このコード
SomeClass* someObject= ...
... use someObject ...
[someObject release];
... more code ...
コードの後半で誤ってアクセスsomeObject
して、クラッシュにつながる可能性があります。だからあなたは言うかもしれません
SomeClass* someObject= ...
... use someObject ...
[someObject release];
someObject=nil;
... more code ...
nil
へのメッセージは無害であるため、より良いでしょう。ただし、この場合、危険を完全に取り除くことができます。
{
SomeClass* someObject= ...
... use someObject ...
[someObject release];
}
... more code ...
ここでは、{...}
ブロックを使用して変数のスコープを制限しています。その後、someObject
later を使用すると、コンパイル時のエラーになります。
特に ivar をリリースする場合、リリース後dealloc
に設定した方がよいかどうかについて、コミュニティでかなりの議論がありnil
ます。
プロゼロ陣営は、一般に、オブジェクトが割り当て解除された後にアクセスされるという不幸なケースで、またはマルチスレッドアプリケーションの場合でも、アプリがクラッシュする可能性が低くなると感じています.
反 nil 陣営は、上記の議論が特に有用であるとは感じていません。なぜなら、アプリケーションに欠陥がある (割り当て解除されたオブジェクトにアクセスしている) ことをより明確にするために、そのような場合にアプリがクラッシュする必要があると考えているからです。
それは必ずしも立場の最も包括的な要約ではありませんが、関係する「論争」のアイデアを提供します.
KVO/KVC の問題は、ivar を nil に設定するかどうかについての議論ではなく、副作用の問題 (KVO/KVC など) の可能性があるため、プロパティのセッターを使用してそうすることが安全かどうかについての議論であるため、多少別個のものです。 .