0

私はObjective-Cクラスを持っており、そのインスタンスは不要になったときにそれを検出して自分自身を破壊することができますが、オブジェクト自体の内部からオブジェクトの自己破壊をトリガーする安全な方法を探しています。破壊を呼び出す」...私のコードはおおよそ次のようになります（簡潔にするために一部削除されています）：

+ (oneway void)destroyInstance:(id)obj {

    printf("Destroying.\n");
    if (obj != nil) {
        free(obj);
        obj = nil;
    }

}

- (oneway void)release {

    _noLongerRequired = [self determineIfNeeded]; // BOOL retVal

    if (_noLongerRequired) {
        [self deallocateMemory]; // Free ivars etc (NOT oneway)
        [MyClass destroyInstance:self]; // Oneway
    }
}

を呼び出すと-release、すぐにメインスレッドに戻るはずです（のためoneway）。

一方、インスタンスが不要になった場合は、onewayクラスメソッドを呼び出してdestroyInstance:、ランタイムから自分自身を削除する必要があります。私の質問は、これは安全ですか？そして、私はoneway正しく使用しましたか？インスタンスが戻る前にインスタンスの関数を破棄する可能性があるように思われます-releaseが、これは...かなり悪いかもしれません。

（追記：明らかにNSObjectなどとは何の関係もありません:)）

4

1 に答える 1

4

これは、作業可能で保守可能なソフトウェアが必要であり、ほぼすべての状況で安全でない場合、間違いなくひどい考えです。しかし、週末にはひどい、安全でないアイデアが楽しいことがあるので、私が識別できる質問の構成要素に答えます。

インスタンスの割り当てが解除されているため、メソッドが「破棄」されることはありません。発生する可能性があるselfのは、メソッドの実行中に割り当て解除されたメモリを指すことになる可能性があることです。つまり、この間にアクセスするselfインスタンス変数またはインスタンス変数がクラッシュする可能性があります。

コードの残りの部分に関しては、 inにobj等しく設定する理由はまったくないので、特に何かを達成しようとしている場合（おそらくオブジェクトへのポインターを出力する場合）、その方法はそれを実行する正しい方法ではありません。nil+destroyInstancenil

の使用について考えるとoneway、この言語が言うことは、このメッセージを送信しても呼び出し元のスレッドがブロックされないということです。オブジェクトを解放するという文脈では、おそらくメッセージのターゲットがそのスレッドによって再び参照されることはないので、それはある程度意味があると思います。+destroyInstanceその論理によって、あなたの宣言はおそらく大丈夫だと思います。retain/競合状態が発生しないように、ある種の同期を提供する必要があるのではないかと思いますが、releaseそれについて考えると、オブジェクトの所有権を取得することはおそらく非同期ではありません。

私の個人的な意見では、このコードを本番環境に導入した人は、おそらく解雇または訴えられるべきだと思います=P。しかし、それが教育目的のみである場合は、楽しんでください。これが役立つことを願っています。

于 2012-10-14T13:56:17.937 に答える