Это, безусловно, работает для объектов, созданных new, и когда вызывающий Update должным образом информируется об этом поведении. Но я бы избежал этого. В вашем случае право собственности явно принадлежит миру, поэтому я бы заставил мир удалить его. Объект не создается сам, я думаю, что он также не должен удалять себя. Может быть очень удивительно, если вы вызываете функцию «Обновление» для вашего объекта, но вдруг этот объект больше не существует, когда Мир ничего не делает из себя (не считая удаления его из своего списка - но в другом кадре! Вызов кода). Обновление об объекте этого не заметит).
Некоторые идеи на этот счет
- Добавить список ссылок на объекты в World. Каждый объект в этом списке ожидает удаления. Это распространенная техника, которая используется в wxWidgets для окон верхнего уровня, которые были закрыты, но все еще могут получать сообщения. Во время простоя, когда все сообщения обрабатываются, список ожидания обрабатывается, и объекты удаляются. Я верю, что Qt следует аналогичной технике.
- Скажите миру, что объект хочет быть удаленным. Мир будет должным образом информирован и позаботится обо всем, что нужно сделать. Что-то вроде
deleteObject(Object&) возможно.
- Добавьте функцию
shouldBeDeleted к каждому объекту, которая возвращает истину, если объект желает быть удаленным его владельцем.
Я бы предпочел вариант 3. Мир назвал бы Обновление. И после этого он проверяет, должен ли объект быть удален, и может ли он сделать это - или, если пожелает, запоминает этот факт, добавляя этот объект в список отложенных удалений вручную.
Боль в заднице, когда вы не можете быть уверены, когда и когда не сможете получить доступ к функциям и данным объекта. Например, в wxWidgets есть класс wxThread, который может работать в двух режимах. Один из этих режимов (называемый «отсоединяемым») заключается в том, что если его основная функция возвращает (и ресурсы потока должны быть освобождены), она удаляет себя (для освобождения памяти, занятой объектом wxThread), вместо того, чтобы ждать владельца потока объект для вызова функции ожидания или соединения. Однако это вызывает сильную головную боль. Вы никогда не можете вызывать какие-либо функции для него, потому что он мог быть прерван при любых обстоятельствах, и вы не можете создать его без использования new. Некоторые люди говорили мне, что им очень не нравится это поведение.
Самостоятельное удаление объекта с подсчетом ссылок пахнет, imho. Давайте сравним:
// 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();
};
Я думаю, что первое намного приятнее, и я считаю, что хорошо спроектированные объекты с подсчетом ссылок не действительно "удаляют это", потому что это увеличивает связь: класс, использующий данные с подсчетом ссылок, должен знать и помните о том, что данные удаляются как побочный эффект уменьшения числа ссылок. Обратите внимание, что «bmp» становится, вероятно, висящим указателем в деструкторе ~ Bitmap. Возможно, не делать это «удалить это» гораздо приятнее здесь.
Ответ на аналогичный вопрос «Какая польза от удаления этого» * 1032 *