Тупость компилятора

[zubr]

Код:

Ну а может моя тупость. В общем история такова. Создаю класс:
[code]
class __declspec(dllexport) CIEFrame
{
private:
    
public:
   CIEFrame();
   virtual ~CIEFrame();

public:
   // указатель на документ фрейма
   void* m_Document;
   // имя  фрейма
   CString Name;
   // индекс фрейма как элемента в списке элементов страницы
   int sourceIndex;
   // указатель на интерфейс IHTMLDocument2 документа фрейма
   void* m_pHtmlDocument;
};

CIEFrame::CIEFrame()
{
    m_Document = new CIEDocument();
};

CIEFrame::~CIEFrame()
{
     delete m_Document;
};

При тестировании программы обнаруживаю утечки памяти. Часа 2 убиваю (проект достаточно большой) на поиски. Обнаруживаю, что при вызове delete m_Document; не вызывается деструктор класса CIEDocument. После того как делаю:

Код:

CIEFrame::~CIEFrame()
{
     delete (CIEDocument*)m_Document;
};

утечки памяти пропадают.
Вот и не понятно:
1. При создании объекта m_Document = new CIEDocument(); компилятор знает, что создается объект CIEDocument, нафига ему для корректного удаления объекта нужно приведение типа.
2. И что же он удаляет в случае delete m_Document;[/code]

[Алексей++]

так всё правильно, а CIEDocument(); какой тип возвращает ? А ты указатель на void используешь. Вот компилятор и не знает, что ему бы ещё и деструктор вызвать
Он просто память по указателю освобождает, не заботясь о том, что там есть указатели на динамическую память (что делает деструктор)

[zubr]

Алексей1153++, указатель на void, но он то на объект CIEDocument указывает и компилятор об этом знает, бо создает этот объект, выделяет память под этот объект, инициализирует переменные в конструкторе и т. д., а при удалении только память освобождает не вызывая деструктор, вот это мне и не понятно.

[Алексей++]

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

[McZim]

zubr, сделай так

Код:

public:
   CIEDocument* m_Document;

...
...
...

CIEFrame::CIEFrame()
{
    m_Document = new CIEDocument();
};

CIEFrame::~CIEFrame()
{
     delete m_Document;
};

[zubr]

McZim, в общем то это не проблема, а философский вопрос (о тупости компилятора). А сделать CIEDocument* m_Document; не могу, так как пересечение возникает. Членом класса CIEDocument является объект класса CIEFrame и наоборот.

[Алексей++]

Зубр , пересечение легко решается

разнести коды классов в пары файлов .h и .cpp . В заголовочных нужно перед определением класса написать предопределение

class mytype1;
class mytype2;
...

далее в заголовке компилятор позволит определять указатели на эти классы

ну и не забыть в cpp вставить инклуды заголовков нужных классов

[McZim]

zubr, ну Леха собственно все сказал, так что это не тупость компилятора.

[Алексей++]

это вообще ничья тупость, все по своему правы - и Зубр , и компилятор ) Но придётся всё таки идти на поводу компилятора, потому что так правильно

[npak]

То, что что хочет zubr называется статическим анализом - компилятор должен проглядеть весь код программы, убедиться, что в m_Document может оказаться только указатель на CIEDocument.

К сожалению, для С++ это пока не решенная теоретическая проблема. Она решена для спецефических языков, вроде Ocaml, но эти языки по эффективности исполнения с С++ и рядом не стоят.

Если же поглядеть в стандарт (раздел 12.4 Destructors), то можно обнаружить такой текст:

a destructor for class X calls the destructors for X’s direct members

Так вот, в языке С++ деструкторы есть только у инстансов классов, у указателей и ссылок деструкторов нет! Пусть даже они указывают самый разобъектный объект с самым деструкторым деструктором, но для компилятора это не имеет значение - если программист пользуется указателями, пускай сам прибирает за собой.

Объяснение очевидно. В С++ нет подсчета ссылок, поэтому компилятор не может дать никаких гарантий, что в момент удаления фрейма на объект, на который указывает m_Document, больше никто не ссылается. Если такие ссылки есть, то после удаления m_Document они провиснут, и обращения к ним приведут, скорее всего, к краху. Разработчики языка решили, что пусть лучше утекает память, чем падают приложения.

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

[Алексей++]

npak, что значит у указателей и ссылок нет деструкторов ? То есть, прямо у них нет, конечно, но деструктор вызовется - тип указателя известен

[Вад]

Объяснение очевидно. В С++ нет подсчета ссылок, поэтому компилятор не может дать никаких гарантий, что в момент удаления фрейма на объект, на который указывает m_Document, больше никто не ссылается. Если такие ссылки есть, то после удаления m_Document они провиснут, и обращения к ним приведут, скорее всего, к краху. Разработчики языка решили, что пусть лучше утекает память, чем падают приложения.

Не понял. Память будет освобождена и с некоторой вероятностью использована снова - и в этом случае всё равно всё упадёт. То, что не будет вызван деструктор, лишь замаскирует проблему. Разве нет?

[npak]

npak, что значит у указателей и ссылок нет деструкторов ? То есть, прямо у них нет, конечно, но деструктор вызовется - тип указателя известен

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

Код:

class C {
    SomeClass m_instance;
    SomeClass * m_ptr;
    SomeClass & m_ref;
};

Для класса С компилятор сгенерирует имплицитный деструктор, который вызовет деструктор объекта m_instance. Два остальных члена класса объектами не являются, деструкторов у них нет, поэтому компилятор для их обработки ничего генерировать не будет.

[npak]

Не понял. Память будет освобождена и с некоторой вероятностью использована снова - и в этом случае всё равно всё упадёт. То, что не будет вызван деструктор, лишь замаскирует проблему. Разве нет?

Если деструктор для *(m_Document) вызван не будет, то память по адресу m_Document не освободиться. Поэтому если кто-то еще содержит указатели на этот адрес, он сможет спокойно читать или писать по этому адресу без риска навредить кому-то еще.  Если же неявный деструктор сделает delete m_Document, то результат предсказать я не берусь. Могут быть самые разные эффекты.

[Алексей++]

насчёт того, что будет лежать по указателю, об этом программист позаботится.

а вот это

. Два остальных члена класса объектами не являются, деструкторов у них нет, поэтому компилятор для их обработки ничего генерировать не будет.

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

[zubr]

Если деструктор для *(m_Document) вызван не будет, то память по адресу m_Document не освободиться.

Почему, освободится, но частично. То есть не освободится память объектов, создаваемых в m_Document динамически и уничтожаемых в деструкторе. Как я понимаю статические объекты все таки должны удалиться и без деструктора.

[Вад]

zubr, вот и я так думаю... Ведь будет освобождён весь блок памяти, выделенный под документ - то есть, размером со всё статическое содержимое (включая указатели - что и приведёт к утечке объектов, на которые они указывают).
Поэтому мне не совсем понятно высказывание npak насчёт краха и утечек. Удалишь при наличии других ссылок - сломается, не удалишь при отсутствии этих ссылок - будут утечки.

[npak]

Удалишь при наличии других ссылок - сломается, не удалишь при отсутствии этих ссылок - будут утечки.

Именно так.

Язык С++ предлагает программисту самому следить за чистотой памяти. Деструкторы вызываются только для тех объектов, которые размещаются внутри удаляемого объекта. Кстати, в свое время Борланд С++ выдавал предупреждение, если метод возвращал указатель на член класса. Объясняли это так - время жизни поля объекта ограничено временем жизни самого объекта, а время жизни внешнего указателя может быть больше, то есть возможен случай, когда объект уже удален со всеми полями, а указатель на поле еще существует. Создатели компилятора в одной из версий такие предупреждения давали, а потом, насколько помню, перестали.

Поскольку проблема общих указателей очень распространена, существуют довольно эффективные решения. Наиболее популярны умные указатели (их я уже упоминал). Правда, они не умеют справляться с циклическими ссылками, но и для этой ситуации есть типовые решения - слабые (weak) указатели.

Так что, если хотите, чтобы компилятор сам подбирал память для указателей, Welcome to Boost!

http://www.codeproject.com/KB/stl/boostsmartptr.aspx
http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/smart_ptr.htm