newの呼び出し元がUpdateその動作について適切に通知されている場合に作成されたオブジェクトに対しては、確かに機能します。しかし、私はそれを避けます。あなたの場合、所有権は明らかに世界にあるので、世界にそれを削除させます。オブジェクトは自分自身を作成しません。自分自身を削除するべきではないと思います。オブジェクトに対して「Update」関数を呼び出した場合、非常に驚くかもしれませんが、World がそれ自体から何も実行せずに、そのオブジェクトが突然存在しなくなります (リストから削除することを除いて、別のフレームで! コードを呼び出すコードオブジェクトの更新はそれに気付かない)。
これに関するいくつかのアイデア
- World へのオブジェクト参照のリストを追加します。そのリスト内の各オブジェクトは削除待ちです。これは一般的な手法であり、wxWidgets で閉じられたがメッセージを受け取る可能性があるトップレベル ウィンドウに使用されます。アイドル時間にすべてのメッセージが処理されると、保留リストが処理され、オブジェクトが削除されます。Qtも同様の手法に従っていると思います。
- オブジェクトが削除されることを世界に伝えます。世界は適切に情報を得て、やらなければならないことは何でも引き受けます。
deleteObject(Object&)多分のような何か。
shouldBeDeleted所有者がオブジェクトを削除したい場合に true を返す関数を各オブジェクトに追加します。
私はオプション 3 を好みます。世界は Update を呼び出すでしょう。その後、オブジェクトを削除する必要があるかどうかを確認し、削除することができます。または、必要に応じて、そのオブジェクトを削除保留中のリストに手動で追加することで、その事実を記憶します。
オブジェクトの関数やデータにアクセスできないのは、いつ、いつなのか分からないときです。たとえば、wxWidgets には、2 つのモードで動作できる wxThread クラスがあります。これらのモードの 1 つ (「デタッチ可能」と呼ばれます) は、そのメイン関数が返された場合 (そしてスレッド リソースを解放する必要がある場合)、スレッドの所有者を待つ代わりに (wxThread オブジェクトによって占有されていたメモリを解放するために) 自分自身を削除します。待機または結合関数を呼び出すオブジェクト。しかし、これは激しい頭痛を引き起こします。どのような状況でも終了する可能性があり、new 以外で作成することはできないため、関数を呼び出すことはできません。かなりの数の人々が、その振る舞いが非常に嫌いだと私に言いました。
参照カウントされたオブジェクトの自己削除は臭いです、私見です。比較してみましょう：
// bitmap owns the data. Bitmap keeps a pointer to BitmapData, which
// is shared by multiple Bitmap instances.
class Bitmap {
~Bitmap() {
if(bmp->dec_refcount() == 0) {
// count drops to zero => remove
// ref-counted object.
delete bmp;
}
}
BitmapData *bmp;
};
class BitmapData {
int dec_refcount();
int inc_refcount();
};
それを、参照カウントされた自己削除オブジェクトと比較してください。
class Bitmap {
~Bitmap() {
bmp->dec_refcount();
}
BitmapData *bmp;
};
class BitmapData {
int dec_refcount() {
int newCount = --count;
if(newCount == 0) {
delete this;
}
return newCount;
}
int inc_refcount();
};
最初のほうがはるかに優れていると思います。適切に設計された参照カウントオブジェクトは「これを削除」しないと思います。これは、結合が増加するためです。参照カウントデータを使用するクラスは、データが自分自身を削除することを知って覚えておく必要があります。参照カウントを減らすことの副作用。~Bitmap のデストラクタで "bmp" がダングリング ポインタになる可能性があることに注意してください。おそらく、ここでは「これを削除」しないほうがずっといいでしょう。
同様の質問への回答「これを削除するのは何ですか」