работа delete

[Malaja]

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

sss,
спасибо за пример! Об этом варианте я не подумала.

[sss]

Не за что Malaja  . Еще надо добавить, что естественно метод Release() и деструктор виртуальные...

[Алексей++]

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

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

[Malaja]

Леш, почему??? В классе деструктор всегда присутствует незримо, даже если ты его не прописываешь!

[Алексей++]

потому что если не объявить в родителе деструктор как виртуальный, то
delete pVirt
вызовет только ~A . Если объявить, то вызовется ~потомок, ~A.

А второй случай всегда правильно вызовет деструкторы

[Malaja]

А ты их совсем замять хотел? Тогда пардон, я думала, что как минимум в классе А ты его объявишь в любом случае... Тогда все ясно. Извини за старческий маразм
Я же не думала, что ты так обидишь деструктор

[Алексей++]

да, я такой

[Антон (LogRus)]

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

Лёха, ты же один хрен объявил виртуальную функцию и  у тебя объект вырос на ptr_size + создалась табилица. ну объяви виртуальный деструктор хотя бы пустой в одном родительском классе. так в чём разница кроме мерзких извращений, не считая случая с подсчётом ссылок.

[Алексей++]

у нас разные взгляды на мир Для меня твои подсчёты ссылок - и есть грязное и )))

[Finch]

Ирин, Как пример: паттерн программирования Singleton. Там правда в статическом методе удаляется класс из памяти. Хотя можно и обычный метод использовать.

[Dimka]

Не пойму я чего-то.

Когда мы объявляем класс B потомком A, а затем приводим объект типа B к типу A, мы используем полиморфизм объекта.

Чтобы полиморфизм объекта работал (в данном случае вызывался нужный деструктор), по синтаксическим особенностям C++  переопределяемые потомками методы необходимо объявить виртуальными, что разрешает полиморфизм объекта.

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

Где логика, где здравый смысл?

[Алексей++]

да одни сплошные эксперименты )

[RXL]

В продолжение темы.

Понимаю, что боян, но очень туго со временем...
Могу ли я удалить динамический объект из его собственного конструктора? Особенно в случае наследования (это MDI форма и у нее автоматом происходит Show()).

Код: (C++)

class A
{
  A(int a) : B(int b)
  {
    delete this;
  };
};

A *a = new A(0);

[Вад]

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

[Алексей++]

можно, только для чего ? )

[Джон]

Ром, в таких случаях лучше всего на нагружать конструктор функциональностью, а использовать ф-ю Init.

[RXL]

Да я уже извернулся - просто сам факт интересен. Ведь после конструктора срабатывают всякие события, а значит в очереди стоят сообщения (вероятно класс-предок послал послал PostMessage).

Для чего все это...
Был диалог, который создавался через new, в его public-члены загружались параметры и вызывался ShowModal. Нужно было быстро переделать его в MDI, но MDI не может быть модальным и, соотв., delete ему в вызывающем коде не сделаешь, а нужно было сделать контроль, чтобы таких диалогов (с данными уникальными параметрами) одновременно был только один. Хотел проверять в конструкторе и удалять сам себя в случае повтора. Решил задачу проверкой вне класса - до создания.

[Джон]

Сам факт - это да. new и delete это по сути операторы С++, в итоге они вызовут ф-ции выдлеления/освобождения памяти, и вот как оно там будет... Надо просто на уровне асма продебажить. Я думаю всё станет ясно.

[RXL]

Не, в дебри асма лезть желания нет. Потом, смениться версия runtime-библиотек и ситуация может измениться.

[Алексей++]

а по моему лучше просто переопределить виртуальную DefWindowProc и поставить заглушку

return 0;

тогда сообщения не обработаются.

[RXL]

Леш, в моем случае это Borland C++ Builder 6 - тут большая классовая надстройка и до корней не докопаешься. Задачу я уже решил - традиционным методом:
1. При создании где-то сохраняем указатель на форму.
2. При закрытии (и самоуничтожении) формы в OnClose это где-то обнуляем.

[Finch]

В свое время, мне посоветовали использовать исключения в данном случае. При ошибке в конструкторе класса вызывать исключение, а уже в основной ветке программы ловить исключения. Также сказали, что класс в данном случае автоматически уничтожается. Хотя я тогда не проверял. Да и в принципе и не использовал данный метод.

[RXL]

При случае попробую.

[Finch]

Сейчас провел эксперементы.

Код:

#include <stdio.h>

class DivideByZeroError
{
public:
   DivideByZeroError():message("Ошибка: Деление на нуль\n") {}//Error: Divide By Zero\n") {}
   void printMessage() const {printf("%s", message);}
private:
   const char *message;
};

class prob
{
public:
   prob() {printf("Constructor\n"); i=new int[20]; throw DivideByZeroError();};
   ~prob() {printf("Destructor\n"); delete [] i;};
private:
   int *i;
   
};

int main()
{
   prob *my=0;
   try
   {
      my = new prob();
   }
   catch(DivideByZeroError error)
   {
      error.printMessage();
      if (my) delete my;
   }
   
   return 0;
}

Объект не создается. Но также и не вызывается деструктор автоматически. Все динамически созданные данные теряются. Поэтому перед throw нужно их удалять.

[Вад]

Finch, поэтому я неоднократно встречал резонную рекомендацию не хранить динамические поля напрямую при небезопасных конструкторах. Скажем, у Мейерса в "More Effective C++". Предлагается помещать их в умные указатели - они, как полностью сконструированные на момент исключения объекты, должны быть удалены корректно при возникновении исключения в конструкторе (их освобождение - как статических элементов - не требует вызова деструктора содержащего их класса, а у них самих деструкторы вызваны будут)

[sss]

Finch, вот возможное решение...

Код:

class A
{
protected:
  void* b;
  A() : b(NULL) {};
  ~A(){ if ( b) free( b);};
}

class B : public A
{
public:
   B() { b = malloc( 100); throw EError;};
}

[Антон (LogRus)]

Объект не создается. Но также и не вызывается деструктор автоматически. Все динамически созданные данные теряются. Поэтому перед throw нужно их удалять.

Это не по стандарту на сколько я знаю, если конструктор пробрался за фигурные скобки значит должен вызваться деструктор. Что за компилятор?

Вад, согласен, так всегда и делаю

[sss]

Это не по стандарту на сколько я знаю, если конструктор пробрался за фигурные скобки значит должен вызваться деструктор. Что за компилятор?

Гм... Интересное замечание. Кажется есть опции в компиляторе меняющие это поведение ( во всяком случае я ловил такие моменты). Если в проекте есть статические и динамические экземпляры лучше на это не полагаться. Кстати, мой пример выше - "умный" базовый класс, который точно уже положил вызов деструктора при раскручивании...

[Finch]

LogRus

~$ g++ --version
g++ (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)

Проверял, что нет течи памяти с помошью valgrind-3.3.0

[Антон (LogRus)]

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