При вызове delete несколько раз,вызывается деструктор столько же раз,че за?

Question

[yanchumak]

Объясните данное поведение, ниже простой код(был под рукой QT на нем и писал):

#include <QCoreApplication>
#include <QDebug>

class Item
{
public:
    Item()
    {
        qDebug() << "Item()" << endl;
    }
    ~Item()
    {
        qDebug() << "~Item()" << endl;
    }
};

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    Item *item = new Item;
    delete item;
    delete item;
    delete item;

    return a.exec();
}

Деструктор будет вызван 3 раза, и так с любым кол-вом delete. Это нормальное поведение? Деструктор же вызвали, объект должен был уйти в утиль,не? или в утиль уходят только внутренние объекты?

Answer 1

[Армянское Радио]

Это C++, детка, здесь могут и ногу отстрелить.

Да, это совершенно нормальное поведение для C++. В угоду переносимости и производительности, здесь никто не проверяет, что объект был ранее уничтожен.

Comments

[yanchumak]

ништяк, повторный delete это плохо? или лучше после delete занулять указатель и при удалении проверять на нул?

[Армянское Радио]

yanchumak: Повторный delete, это плохо, очень плохо. И зануление указателя - тоже плохо.

Чуть лучше писать в указатель значение nullptr, и проверять перед удалением.

А еще лучше, пересмотреть архитектуру и использовать умные указатели.

[yanchumak]

Армянское Радио: понял,спасибо

[maaGames]

yanchumak: Проверять перед удалением не нужно, delete сам проверяет, что указатель не нуль. А вот обнулять очень нужно. А ещё лучше, не использовать голый указатель.

[yanchumak]

maagames.ru: хм,одни говорят нужно обнулять указатель,другие нет,так где правда?

[Армянское Радио]

yanchumak: Необходимость обнуления мотивируют "безопасным стилем программирования". Фактически, возможность безопасно скормить delete nullptr вместо указателя - это такой костыль в языке, чтобы криворуким авторам программ было удобнее.

Если у вас в программе обстоятельства складываются так, что объект может быть удален дважды, стоит в первую очередь подумать над архитектурой, а потом вбивать костыли в виде delete с последующим обнулением.

[yanchumak]

Армянское Радио: толково объяснилс,спасибо еще раз.

[maaGames]

yanchumak: Обнулять банально удобно. Точнее, даже не обнулять, а записывать туда удобный мусор. Какую-нибудь удобночитаемую константу, например 0xDEADBEEF. Таким образом можно различить указатель, которому никогда не было присвоено значение от указателя, который был удалён. Проверять указатель на ноль перед вызовом delete смысла нет, потому что delete в первую очередь сам проверяет указатель на ноль.
А ещё лучше используй smart_ptr и забудь о delete.

[Армянское Радио]

maagames.ru: "использовать умный указатель и забыть о delete" - это в рубрику "вредные советы по превращению C++ в Java".

[maaGames]

Армянское Радио: Нет. Если ты не умеешь нормально пользоваться умными указателями, то это исключительно твои проблемы. Может ещё std::vector не нужно использовать, вместо T* = new T[xxx] ?

[Армянское Радио]

maagames.ru: предлагаю во-первых не переходить на панибратский тон, во-вторых, каждую задачу решать отдельно и соизмерять удобство, привносимое STL и BOOST с оверхедом, который они неизбежно притянут за собой.

Если мне нужен банальный статический массив, который никогда не будет расти, я использую или new T[] или std::array, но не std::vector.

Каждой задаче - свой инструмент. А не свалка "лучших практик от гуру".

[maaGames]

Армянское Радио: Уважаемое Армянское Радио, приведите, пожалуйста, хотя бы один пример, когда оверхед от auto_ptr превышает пользу он его использования? Перефразирую. Чем вызов delete отличается от вызова delete в заинлайненом деструкторе? Я сам могу ответить, что ничем, но вдруг...

[yanchumak]

Армянское Радио: вопрос немного не по теме: статические массивы лучше из кучи брать? или на стеке? или же от размера зависит?

[Армянское Радио]

maagames.ru: А оверхед на содержание смартпоинтера вы учли? На то, что при каждом копировании у вас не просто одна инструкция mov, а целый вызов метода, который должен увеличить счетчик ссылок? А если копируется миллион экземпляров?
Тактика умных указателей не всегда оправдана.
Иногда вариант собственным пулом объектов и собственным менеджером памяти оказывается эффективнее.

yanchumak: все зависит от задачи. И от размера - огромный массив просто не поместится на стеке.

[maaGames]

Армянское Радио: Так я же хитрый! Поэтому и написал auto_ptr, а не smart_ptr. auto_ptr это "синоним" scope_ptr, так что никакой семантики копирования.

Я абсолютно с вами согласен, что умные указатели не нужно пихать повсюду. Я категорически не согласен, что умный указатель это вредный совет. Отказ от умных указателей и прочих плюшек это преждевременная оптимизация. Если я могу что-то не делать, я этого не делаю. Если могу заставить делать компилятор что-то вместо меня - я это делаю.

[Армянское Радио]

maagames.ru: наше с вами обсуждение сейчас строится вокруг отсутствующей задачи, даже гипотетической. Решать вопрос о том, какие тактики использовать можно, имея перед собой задачу, либо формальное описание класса задач.

Вы в категоричной форме дали совет использовать умный указатель и забыть про delete, я написал, что такая категоричность - вредна.

[maaGames]

Армянское Радио: Юношеский максимализм.)

Answer 2

[tsarevfs]

Невиртуальные методы представляют собой обычные функции, которые получают неявный праметр this на экземпляр класса. Получается что даже код.

A *a = NULL;
a->f();

скомпилируется, но будет работать неправильно.
При вызове нестатических методов (включая деструктор) и обращении к нестатическим полям вы должны гарантировать:
1. вызвался конструктор, объект существует
2. не вызывался деструктор, объект еще не удален

Comments

[drozdVadym]

будет работать неправильно если в функции f() идет доступ к памяти класса.

Answer 3

[valent_in_habrahabr]

У меня вопрос(опытные люди, ответе мне, у кого стаж более 3-5 лет на с++) это выражение

"здесь могут и ногу отстрелить."

. применяют те кто изучали С++ по youtube? Дело в том, что я изучал С++ по классическим учебникам и всегда следовал правилам придуманные не для того, что бы их нарушали. И я не могу понять как в С++ себе можно ногу отстрелить, если строго следовать правилам? Или это всего навсего выражение новичков/быдлокодеров которые погорели из-за невнимательности на таких вещах как работа с памятью(как пример)? Я может не знаю, что то? Подскажите.

Есть правила, есть стандарты которые придумали умные люди что бы им придерживались а не нарушали!

Item *item = new Item;
delete item;
delete item;
delete item;

Вы заняли память потом её освободили, на этом всё. Как вы освободите повторно уже пустой раздел памяти(который освободили уже)?

Comments

[asd111]

про правила вы правы, но в большой программе легко накосячить, например почитайте блог PVS-Studio на хабре. они как раз рассматривают ошибки в очень больших программных продуктах на С++. которые были написаны профессионалами habrahabr.ru/search/?q=pvs

[valent_in_habrahabr]

asd111: Понятно, что в большом проекте такое может быть. Но это же не зависти от ЯП(в данном случае, если говорим про С++). Сейчас существуют огромное кол-во инструментов и прочего, для исключения таких ошибок. Даже я как новичок понимаю, что надо владеть теорией полностью и тогда ошибок не будет таких ну и разумеется внимательность. Я могу привести в аналогию внимательность и точность математиков при работе. Информатика же наука. А значит надо работать осторожно и точно. А выстрелить в ногу можно и покупая молочко/хлебушек в магазине.

[tugo]

Но это же не зависит от ЯП

Зависит.
В C# (к примеру) отсутствует необходимость ручном удалении объектов, такие ошибки исключены.

[valent_in_habrahabr]

tugo: в java тоже есть сборщик мусора. Только я имел в виду другое. На бога надейся а сам не плошай. Так и здесь. Нужно придерживаться стандартам языка и не думать, что уже существуют волшебные компиляторы.

[Don Kaban]

Стандартов языка стоит придерживаться авторам компиляторов (и я сейчас про нормальные, а есть же и msvc :). Тешить же себя надеждой "я все делаю правильно" - получится у вас до превого проекта, чуть больше чем хелловорд.

[yanchumak]

valent_in_habrahabr: сборщик, но утечку памяти можно схлопотать даже проще, чем на ++. по логике: у меня же есть сборщик мусора, он там всё сам сделает.

[Армянское Радио]

valent_in_habrahabr: о, это я только сейчас увидел ваш комментарий.

Могли бы и на меня сослаться, чтобы гарантированно привлечь мое внимание. Не подумали об этом? Не знали, что есть возможность написать мой ник с собачкой в начале(Армянское Радио), чтобы у меня появилось уведомление?

Поздравляю - вы также не идеальный человек, который может наделать глупостей, и чьи знания на 100 процентов не совпадают с реальностью.

Возможность отстрела ног на C++ - это не про "изучение C++ по youtube", а вполне себе мем субкультуры программистов на C++, который получил известность, благодаря книге Голуба "Веревка достаточной длины, чтобы выстрелить себе в ногу". Как?! Вы и об этом не знали?!

Суть мема - C++ является очень тонкой прослойкой между программистом и железом, которая очень доверчива к программисту. А программист (даже со знанием стандартов, применением правил и так далее) - увы - ошибается.

И дело даже не в том что вроде как "программист не железный, вот и ошибается" - железо тоже ошибается.

Резюмирую - по ногам себе стреляют не только джуниоры, изучавшие C++ за 21 день, но и маститие глыбы, вроде Кармака. А C++ просто ничем от такой стрельбы не защищает.

[valent_in_habrahabr]

Армянское Радио: спасибо за ответ. Книгу прочитаю. Думаю будет познавательно. Буду хоть иметь представление "как отстрелить себе ногу".

[Александр Таратин]

Don Kaban: И чем вам не угодил msvc? Если рассматривать последний 2013. Все очень даже прилично
msdn.microsoft.com/ru-ru/library/hh567368.aspx

[Don Kaban]

Александр Таратин
Я вообще виндовс как платформу для программирования давно уже не воспринимаю. Хотя, возможно это особенности именно моего организма.

[Don Kaban]

msdn.microsoft.com/ru-ru/library/hh567368.aspx - ну убого же.