Почему деструкторы требуются в C++?
Попробуйте это:
var local = location.hostname;
var dodlink = document.createElement('a');
dodlink.href = "http://" + local + "/DoD/";
var dodimg = document.createElement("img");
dodimg.setAttribute("src", "DOD.png");
dodimg.setAttribute("width", "256");
dodimg.setAttribute("height", "256");
dodlink.appendChild(dodimg);
document.getElementById("Images").appendChild(dodlink);
var derlink = document.createElement('a');
derlink.href = "http://" + local + "/DER/";
var derimg = document.createElement("img");
derimg.setAttribute("src", "DER.png");
derimg.setAttribute("width", "256");
derimg.setAttribute("height", "256");
derlink.appendChild(derimg);
document.getElementById("Images").appendChild(derlink);
5 ответов
Если Вы спрашиваете, почему классы C++ имеют деструкторы, некоторые классы имеют требования кроме просто освобождения памяти. У Вас может быть объект, это выделило сокетное соединение, которое должно быть закрыто чисто, например.
Кроме того, 'необзор' указателя не освобождает память, на которую он указывает на то, так как другие указатели могут ссылаться на него.
Если у Вас будет указатель на стеке, то выходить из функции освободит память, используемую указателем, но не что память, на которую указывает указатель. Существует тонкое, но очень важное различие.
Когда указатель выходит из объема, память, взятая указателем, освобождена. 4 или 8 байтов (обычно) памяти, которые взяты указателем, который является.
Объект (или другая память), на который указывает указатель, не выпущен, когда указатель выходит из объема. Вы делаете это delete'ing указатель. И это вызывает деструктор, если существует кто-либо.
Если вы пишете хороший C ++, у вас должно быть очень мало деструкторов (на самом деле я думаю, что «несколько деструкторов» - это хороший показатель качества кода C ++).
Несколько исключений Я могу думать о:
а) Когда вы работаете с вещами, которые не разрушают себя, например. «FILE *».
b) Когда вы используете идиому «pimpl» (в переводе с «идиома pimpl»).
nb. Классы, такие как std :: auto_ptr и std :: vector, попадут в категорию (a), потому что в какой-то момент им понадобится указатель на память в стиле C.
Когда когда-либо существует указатель (существуйте как участник класса), должен быть деструктор для того класса, который должен удалить объект, на который указывает участник указателя. Если у Вас есть smart_pointer вместо указателя в классе затем нет никакой потребности деструктора.
ниже qn поможет u понять лучше. Будет ниже утечки памяти причины кода в C++
Во-первых, Вы по ошибке заявляете, что память освобождена, когда указатель выходит из объема. С необработанными указателями, который является ложью, память потеряна, и любой ресурс, сохраненный резким объектом с нею.
Деструкторы являются базовой функцией языка и основой для идиомы RAII для управления ресурсами. Объекты получают ресурсы во время конструкции, и высвобождает те те же средства в деструкторе. Это - простой, управляемый и простой подход к управлению ресурсами. Обратите внимание здесь, что ресурс - что-либо из памяти (деструкторы интеллектуальных указателей освобождают память, которой они управляют, контейнеры освобождают свою структуру внутренней памяти) или любой другой ресурс (ofstreams выпуск открытые файлы, соединения с базой данных освобождают сокеты).
В то время как с управляемыми языками как C# или память Java выпущен автоматически сборщиком "мусора", это - только память, которая получает realeased, и у пользователя есть деформация управления всеми другими ресурсами вручную вместо использования.
При проверке управляющих структур исключения в C#/Java, Вы заметите, что существует наконец пункт, не существующий в C++. Причина состоит в том, что управляемые языки должны предоставить пользователю блок кода, который, как гарантируют, будет выполнен для ручного освобождения ресурсов. Деформация высвобождения средств помещается в программиста, который пользуется библиотеками.
В C++, с помощью идиомы RAII, каждый объект ответственен за ресурсы, которые это содержит и должно выпустить их во время разрушения. Это подразумевает, что, если Вы используете объекты в ресурсах стека, будет выпущен без взаимодействия пользователя. Ответственность за управление ресурсами находится в классе, и пользователь не должен помнить освобождать каждый ресурс вручную.
Многие управляемые ответчики языка с удовольствием говорят, что не необходимость помнить, когда или где освободить память, поскольку она будет требоваться сборщиком "мусора", является большим преимуществом, но они не войдут в обсуждение того, как управляют другими ресурсами. Управление памятью является просто подмножеством проблемы управления ресурсами, и то же решение применяется. Если Вы держите память в интеллектуальных указателях (станд.:: auto_ptr, повышение:: shared_ptr, станд.:: tr1:: unique_ptr, станд.:: tr1:: shared_ptr..., выберите тот, который соответствует Вашему использованию), затем, памятью будут управлять для Вас.
В то время как это сообщение, кажется, имеет disgressed от исходного вопроса деструкторов, это действительно очень тесно связано. Все управление ресурсами должно быть выполнено в деструкторах, именно так интеллектуальные указатели работают: то, когда стек выделил интеллектуальный указатель, выходит из объема, которым называют деструктор, и он проверяет, называют ли "кучу" (новая) выделенная память должна быть освобождена и если так, удалить. Но с другой стороны, это - просто подмножество более общей проблемы.