Re: delete - C/C++

Допустим есть такой код:

void* p = new CString;
<...>
delete p;
p = new CMyCoolClass;
<...>
delete p;

Будут ли вызываться деструкторы в этом случае? Нажимая Ф11 я этого не заметил, однако утечек памяти тоже нет.

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

А>Допустим есть такой код:
А>

А>void* p = new CString;
<...>>
А>delete p;
А>p = new CMyCoolClass;
<...>>
А>delete p;
А>

А>Будут ли вызываться деструкторы в этом случае? Нажимая Ф11 я этого не заметил, однако утечек памяти тоже нет.

Здравствуйте, Аноним, Вы писали:

А>Допустим есть такой код:
А>

А>void* p = new CString;
<...>>
А>delete p;
А>p = new CMyCoolClass;
<...>>
А>delete p;
А>

А>Будут ли вызываться деструкторы в этом случае?
Нет, не будут
А>Нажимая Ф11 я этого не заметил, однако утечек памяти тоже нет.
А ты присвой своей строке какое-нибудь значение.

Здравствуйте, Аноним, Вы писали:

А>Допустим есть такой код:

А>void* p = new CString;
<...>>
А>delete p;
А>p = new CMyCoolClass;
<...>>
А>delete p;

А>Будут ли вызываться деструкторы в этом случае? Нажимая Ф11 я этого не заметил, однако утечек памяти тоже нет.

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

Здравствуйте, Аноним, Вы писали:

А>Допустим есть такой код:
А>

А>void* p = new CString;
<...>>
А>delete p;
А>p = new CMyCoolClass;
<...>>
А>delete p;
А>

А>Будут ли вызываться деструкторы в этом случае? Нажимая Ф11 я этого не заметил, однако утечек памяти тоже нет.

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

Здравствуйте, Bell, Вы писали:

Более того, в данном случае поведение вообще не определено:

5.3.5/3
In the first alternative (delete object), if the static type of the operand is different 
from its dynamic type, the static type shall be a base class of the operand’s dynamic 
type and the static type shall have a virtual destructor or the behavior is undefined.

V>P.S. Стиль отвратительный.

Придумай лучше. Любые предложения будут с благодарностью рассмотрены.

Для синтаксического разбора методом рекурсивного спуска имеется структура:

struct TERM
{
    enum TERM_TYPE { NUM, STR, GRAPH };
    TERM_TYPE Type;

    double*   m_pNum;
    CString*  m_pStr;
    CGraph*   m_pGraph;
};

(Конструкторы и деструкторы опущены)

Она описывает текущий терм: переменную или результат операции над ними. Переменные могут быть числовыми (double), строковыми (CString) и графиками. (Это довольно сложная структура, поэтому не будем вдаваться в подробности.)

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

А держать в структуре несколько указателей не хотелось бы. Поэтому возникла идея сделать один общий указатель.

А у вас какие идеи?

Здравствуйте, Аноним, Вы писали:

V>>P.S. Стиль отвратительный.

А>Придумай лучше. Любые предложения будут с благодарностью рассмотрены.

А>Для синтаксического разбора методом рекурсивного спуска имеется структура:
А>

А>struct TERM
А>{
А>    enum TERM_TYPE { NUM, STR, GRAPH };
А>    TERM_TYPE Type;

А>    double*   m_pNum;
А>    CString*  m_pStr;
А>    CGraph*   m_pGraph;
А>};
А>

(Конструкторы и деструкторы опущены)

А>Она описывает текущий терм: переменную или результат операции над ними. Переменные могут быть числовыми (double), строковыми (CString) и графиками. (Это довольно сложная структура, поэтому не будем вдаваться в подробности.)

А>В процессе разбора тип терма может измениться. Например, если после переменной типа "график" стоит команда получения его имени, то терм превращается в строку и дальше он рассматривается как строковая переменная. Поэтому нельзя сделать для терма базовый класс и несколько производных — как положено согласно "святому писанию".

А>А держать в структуре несколько указателей не хотелось бы. Поэтому возникла идея сделать один общий указатель.

А>А у вас какие идеи?

то есть ты так что ли сделал?

 struct TERM
 {
    enum TERM_TYPE { NUM, STR, GRAPH };
    TERM_TYPE Type;
    void *p;
 };

B_A>то есть ты так что ли сделал?

B_A>

B_A> struct TERM
B_A> {
B_A>    enum TERM_TYPE { NUM, STR, GRAPH };
B_A>    TERM_TYPE Type;
B_A>    void *p;
B_A> };
B_A>

Хотел так. Но при удалении деструкторы действительно не вызываются. Хотелось бы узнать кошерное решение.

Здравствуйте, Аноним, Вы писали:

<skip>

Может объединение сделать ?

struct TERM
{
    enum TERM_TYPE { NUM, STR, GRAPH };
    TERM_TYPE Type;

    union ptrunion
    {
      double*   pNum;
      CString*  pStr;
      CGraph*   pGraph;
    
      // для удобств :))
      operator double* () { return pNum;}
      operator CString* () { return pStr; }
      operator CGraph* () { return pGraph; }
    }ptr;
};

Здравствуйте, _nn_, Вы писали:

__>Может объединение сделать ?

Может. Но это тоже не кошерно.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, _nn_, Вы писали:

__>>Может объединение сделать ?

А>Может. Но это тоже не кошерно.

А почему ?

Здравствуйте, Аноним, Вы писали:

А>Никто не знает, что будет происходить в этом случае. Неопределенное поведение, однако.

Да, да! Саттер даже пишет, что "компилятор может вставить здесь код, форматирующий Ваш винчестер"

__>>>Может объединение сделать ?

А>>Может. Но это тоже не кошерно.

__>А почему ?

Не знаю.

Но так говорят Знатоки Стандарта и Почитатели Страуструпа. А еще они не любят void*

Я-то наверное оставлю все как было, потому как экономить память здесь ни к чему. Но мне стало интересно, а как в таком случае поступают "правильные программисты"?

Здравствуйте, Аноним, Вы писали:
[]
А>Хотел так. Но при удалении деструкторы действительно не вызываются. Хотелось бы узнать кошерное решение.

А boost использовать не хочется?

__>>>>Может объединение сделать ?

А>>>Может. Но это тоже не кошерно.

__>>А почему ?

А>Не знаю.

Но так говорят Знатоки Стандарта и Почитатели Страуструпа.
Да нет, объединение само по себе не трефное. Плохо, когда пишут в один член объединения, а читают из другого (a-la hibyte-lowbyte). А в "законном" использовании ничего плохого нет.
А>А еще они не любят void*
А за что его любить? Для нашей же пользы С++ — строго типизированный язык. А ты отказываешься от руки помощи компилятора

А>А boost использовать не хочется?

А как? Что именно?

Здравствуйте, Аноним, Вы писали:

А>Допустим есть такой код:
А>

А>void* p = new CString;
<...>>
А>delete p;
А>p = new CMyCoolClass;
<...>>
А>delete p;
А>

А>Будут ли вызываться деструкторы в этом случае? Нажимая Ф11 я этого не заметил, однако утечек памяти тоже нет.

А шаблоны на что?

S> А шаблоны на что?

Не получится

Здравствуйте, Вы писали:

> Придумай лучше. Любые предложения будут с благодарностью рассмотрены.

> Для синтаксического разбора методом рекурсивного спуска имеется структура:
>

 > struct TERM
 > {
 >     enum TERM_TYPE { NUM, STR, GRAPH };
 >     TERM_TYPE Type;

 >     double*   m_pNum;
 >     CString*  m_pStr;
 >     CGraph*   m_pGraph;
 > };
 >

> (Конструкторы и деструкторы опущены)

class TermData
{
public:
  virtual ~TermData() { }

  . . .
};

class NumData : public TermData
{
  . . .
};

class StrData : public TermData
{
  . . .
};

class GraphData : public TermData
{
  . . .
};

struct Term
{
  . . .

  TermData* term;
};

Posted via RSDN NNTP Server 1.7 "Bedlam"

	От:	Аноним
	Дата:	27.11.03 09:44
	Оценка:

	От:	Vamp
	Дата:	27.11.03 09:51
	Оценка:

	От:	Bell
	Дата:	27.11.03 09:53
	Оценка:

	От:	Аноним
	Дата:	27.11.03 10:00
	Оценка:	+2

	От:	diamond666
	Дата:	27.11.03 10:22
	Оценка:

От:	Вадим Никулин	Здесь
Дата:	27.11.03 13:08
Оценка:

	От:	Павел Кузнецов
	Дата:	27.11.03 15:10
	Оценка:	+2