- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
if (dequeueBuffer_) {
delete dequeueBuffer_;
dequeueBuffer_ = NULL;
}
if (enqueueBuffer_) {
delete enqueueBuffer_;
enqueueBuffer_ = NULL;
}
if (readBuff_) {
delete[] readBuff_;
readBuff_ = NULL;
}
if (currentEvent_) {
delete currentEvent_;
currentEvent_ = NULL;
}
Follow us!
2) google smart pointers
Хм, можно ссылку на гугловскую либу со смартпоинтерами?
В гуглокрестостайлгайде они советуют юзать обычный unique_ptr...
Ну, или селбри в Лоджбане.
Для заимствованых слов есть фонетическая транскрипция, но она иногда больше напоминает японский чем что либо еще. С непривычки иногда очень сложно угадать знакомые слова.
delete[] readBuff_;
readBuff_ = NULL;
}
Такие конструкции излишни. Можно сделать просто delete readBuff_, т.к. в случае не NULL память освободится, а в противном случае стандарт гарантирует корректную работу. Присваивание NULL в деструкторе имхо бессмысленно.
Проверка на NULL говорит о том, что непонятно где указатель инициализируется, может в каком-то методе Init. А должен инициализироваться в конструкторе.
Это конечно если не говорить об использовании smart pointer. Имхо здесь они специально не используются в угоду производительности.
У std::auto_ptr, std::unique_ptr и boost::scoped_ptr производительность ну всяко не хуже ;)
Асинхронный сервак, 90+ классов, ни одного деструктора, ни одного delete, полёт нормальный ;)
Зато удобней на порядок: писать меньше, и невозможно забыть delete ;)
Давно отошёл от С++, может скажу глупость:)
Возможно присваиванием NULL хотят упростить жизнь деструкторам наследников или потомков объекта?.. Если код очень давнишний (старше самого Facebook-а), то такое могло случиться.
Деструкторы наследников вроде бы уже вызваны, если работает деструктор предка.
Как именно можно упросить жизнь?
Есть мнение что такие финты, когда один объект удаляет что-то, что может понадобиться другому объекту не есть хорошо. Есть класс, у него есть "область ответственности" по переменным, он не должен инициализировать/удалять что-то из родительских/дочерних классов.
Зачем? Здесь явное отношение владения. scoped_ptr, auto_ptr, unique_ptr вполне решают задачу.
> случайное обращение к полю удалённого объекта
man valgrind. Под эту вашу винду тоже должны быть аналоги. Никакого повода уродовать код присваиванием NULL'ов в деструкторе ради этого не вижу. В конце-концов, в отладочных целях, можно ведь немного похачить стандартную либу, заставив ее занулять память при деаллокации.
> краш вместо UB
Разыменование нулевого указателя - UB, несмотря на то, что чаще всего оно крашится. (c++98, 1.9 Program execution, пункт 4: Certain other operations are described in this International Standard as undefined (for example, the effect of dereferencing the null pointer).
А какое дело деструкторам потомков до полей родителя? :)
Если они туда лезут, особенно в деструкторе - то программист явно неадекват.
А предок к потомкам в деструкторе вообще слазить не может. Ибо потомка уже нет.
Но если в ГК некоторые объекты дружественные, или имеют статические данные?.. Конечно, без описания класса и его конструктора, можно разное говорить о деструкторе и его поведении.
Более того, если указатель не проинициализирован в конструкторе (хотя бы NULL'ом), то в нем будет мусор. Из-за этого проверка на не NULL с ненулевой вероятностью будет успешной и delete запорет кучу или крашнется ;)
Чесн-слово Сишка гороздо приятней.