Почему деструкторы требуются в C ++?

Когда указатель выходит из области видимости, его память освобождается, так почему же он destructorсоздан в c ++?

9 c++
13.12.2008 11:05:46
5 ОТВЕТОВ
РЕШЕНИЕ

Если вы спрашиваете, почему классы C ++ имеют деструкторы, у некоторых классов есть требования, отличные от просто освобождения памяти. Например, у вас может быть объект, которому выделено сокетное соединение, которое нужно аккуратно отключить.

Кроме того, «unscoping» указатель не освобождает память, на которую он указывает, так как другие указатели могут ссылаться на него.

Если у вас есть указатель на стек, выход из функции освободит память, используемую указателем, но не ту память, на которую указывает указатель. Есть тонкое, но очень важное различие.

18
20.02.2012 10:31:38

Когда указатель выходит из области видимости, память, занятая указателем , освобождается. 4 или 8 байтов (обычно) памяти, которые используются указателем, то есть.

Объект (или другой памяти) , что указатель указывает на это не выпущен , когда указатель выходит из области видимости. Вы делаете это удаление «ИНГ указатель. И это вызывает деструктор, если таковой имеется.

14
13.12.2008 11:14:00

Когда есть указатель (существует как член класса), для этого класса должен существовать деструктор, который должен удалять объект, указанный членом указателя. Если у вас есть smart_pointer вместо указателя в классе, тогда нет необходимости в деструкторе.

ниже qn поможет вам лучше понять. Будет ли приведенный ниже код причиной утечки памяти в C ++

0
23.05.2017 10:32:49

Во-первых, вы ошибочно утверждаете, что память освобождается, когда указатель выходит из области видимости. С необработанными указателями, которые являются ложными, память теряется, и любой ресурс, удерживаемый указанным объектом с ним.

Деструкторы - это основная особенность языка и основа RAII для управления ресурсами. Объекты получают ресурсы во время строительства и высвобождают те же ресурсы в деструкторе. Это простой, контролируемый и простой подход к управлению ресурсами. Обратите внимание, что ресурс - это что-либо из памяти (умные деструкторы-указатели освобождают память, которой они управляют, контейнеры освобождают свою внутреннюю структуру памяти) или любой другой ресурс (ofstreams освобождает открытые файлы, соединения с базой данных освобождают сокеты).

Хотя при использовании управляемых языков, таких как C # или Java, сборщик мусора автоматически освобождает память, освобождается только память, а пользователю приходится вручную контролировать все другие ресурсы по месту использования.

Если вы проверите структуры управления исключениями в C # / Java, вы заметите, что в C ++ отсутствует предложение finally. Причина в том, что управляемые языки должны предоставлять пользователю блок кода, который гарантированно будет выполнен для освобождения ресурсов вручную. Направление освобождения ресурсов лежит на программиста, который использует библиотеки.

В C ++, используя идиому RAII, каждый объект отвечает за ресурсы, которые он содержит, и должен освобождать их во время уничтожения. Это подразумевает, что если вы используете объекты в стеке, ресурсы будут освобождены без участия пользователя. Ответственность за управление ресурсами лежит на классе, и пользователь не должен забывать освобождать каждый ресурс вручную.

Многие обвиняемые в управляемом языке с радостью говорят, что отсутствие необходимости помнить, когда или где освободить память, как это будет требоваться сборщиком мусора, является большим преимуществом, но они не будут обсуждать, как контролируются другие ресурсы. Управление памятью является лишь частью проблемы управления ресурсами, и применяется то же решение. Если вы удерживаете память внутри интеллектуальных указателей (std :: auto_ptr, boost :: shared_ptr, std :: tr1 :: unique_ptr, std :: tr1 :: shared_ptr ..., выберите тот, который вам подходит), тогда память будет управляться для вас.

Хотя этот пост, похоже, не согласен с первоначальным вопросом о деструкторах, он действительно очень тесно связан. Все управление ресурсами должно осуществляться в деструкторов, то есть , как работают умные указатели: когда стек выделяется смарт - указатель выходит из области видимости деструктор вызывается и проверяет , должна ли быть выпущена куча (новая) выделенная память и если да, то на удаление IS называется. Но опять же, это лишь часть более общей проблемы.

9
13.12.2008 12:31:34

Если вы пишете хороший C ++, у вас должно быть очень мало деструкторов (на самом деле я думаю, что «несколько деструкторов» - это хороший показатель качества кода C ++).

Несколько исключений, о которых я могу подумать:

а) Когда вы работаете с вещами, которые не разрушают себя, например. "ФАЙЛ*".

б) Когда вы используете идиому "pimpl" (Google для "идиома pimpl").

в северном направлении Классы, такие как std :: auto_ptr и std :: vector, попадут в категорию (a), потому что в какой-то момент им потребуется указатель в стиле C на память.

0
22.04.2009 10:19:35