Чем может грозить такое удаление( без вызова деструктора ) POD?

    std::list< Foo* >        lst;

    lst.push_back( new Foo );

    std::for_each(
            lst.begin(),
            lst.end(),
            static_cast< void(__cdecl*)(void*) >( ::operator delete )
        );

Для POD не нужно вызывать деструктора, т.к. по определению POD'a у него нет деструкторов или членов (в том числе и подобъектов базового класса), имеющих деструктор.

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

L_L>Для POD не нужно вызывать деструктора, т.к. по определению POD'a у него нет деструкторов или членов (в том числе и подобъектов базового класса), имеющих деструктор.

ГМ, он есть у POD — автоматически сгенерированный ( и что в нем — стандарт не специфицирует ), и вопрос именно в этом, чем грозит освобождение памяти занимаемой POD без вызова автоматически сгенирированного деструктора ?

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

S>Чем может грозить такое удаление( без вызова деструктора ) POD?

Тем, что фрагмент кода внизу ill-formed и может не скомпилироваться.

S>    std::list< Foo* >        lst;

S>    lst.push_back( new Foo );

S>    std::for_each(
S>            lst.begin(),
S>            lst.end(),
S>            static_cast< void(__cdecl*)(void*) >( ::operator delete )
S>        );

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

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

L_L>>Для POD не нужно вызывать деструктора, т.к. по определению POD'a у него нет деструкторов или членов (в том числе и подобъектов базового класса), имеющих деструктор.

S>ГМ, он есть у POD — автоматически сгенерированный ( и что в нем — стандарт не специфицирует ), и вопрос именно в этом, чем грозит освобождение памяти занимаемой POD без вызова автоматически сгенирированного деструктора ?

S>

Ничем. Стандарт явно об этом говорит.

A program may end the lifetime of any object by reusing the storage which the object occupies or by
explicitly calling the destructor for an object of a class type with a non-trivial destructor. For an object of a
class type with a non-trivial destructor, the program is not required to call the destructor explicitly before
the storage which the object occupies is reused or released; however, if there is no explicit call to the
destructor or if a delete-expression (5.3.5) is not used to release the storage, the destructor shall not be
implicitly called and any program that depends on the side effects produced by the destructor has undefined
behavior.

Если деструктор у класса тривиальный, его можно не вызывать, а просто освободить память. Это относится как к POD типам, так и к болеее широкому класссу типов с тривиальным деструктором.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

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

S>>Чем может грозить такое удаление( без вызова деструктора ) POD?

E>Тем, что фрагмент кода внизу ill-formed и может не скомпилироваться.

Вы имеете в виду reinterpret_cast ?

E>

S>>    std::list< Foo* >        lst;

S>>    lst.push_back( new Foo );

S>>    std::for_each(
S>>            lst.begin(),
S>>            lst.end(),
S>>            static_cast< void(__cdecl*)(void*) >( ::operator delete )
S>>        );
E>

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

Ш>Ничем. Стандарт явно об этом говорит.

Ш>A program may end the lifetime of any object by reusing the storage which the object occupies or by
Ш>explicitly calling the destructor for an object of a class type with a non-trivial destructor. For an object of a
Ш>class type with a non-trivial destructor, the program is not required to call the destructor explicitly before
Ш>the storage which the object occupies is reused or released; however, if there is no explicit call to the
Ш>destructor or if a delete-expression (5.3.5) is not used to release the storage, the destructor shall not be
Ш>implicitly called and any program that depends on the side effects produced by the destructor has undefined
Ш>behavior.

Ш>Если деструктор у класса тривиальный, его можно не вызывать, а просто освободить память. Это относится как к POD типам, так и к болеее широкому класссу типов с тривиальным деструктором.

Спасибо

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

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

L_L>>Для POD не нужно вызывать деструктора, т.к. по определению POD'a у него нет деструкторов или членов (в том числе и подобъектов базового класса), имеющих деструктор.

S>ГМ, он есть у POD — автоматически сгенерированный ( и что в нем — стандарт не специфицирует ), и вопрос именно в

Да, надо было сказать нет определенного пользователем деструктора. Но собственно, POD имеет и другие ограничения, так что ясно, что деструктор у него — тривиальный, который как говорит стандарт ... implicitly-declared.

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

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

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

L_L>>>Для POD не нужно вызывать деструктора, т.к. по определению POD'a у него нет деструкторов или членов (в том числе и подобъектов базового класса), имеющих деструктор.

S>>ГМ, он есть у POD — автоматически сгенерированный ( и что в нем — стандарт не специфицирует ), и вопрос именно в

L_L>Да, надо было сказать нет определенного пользователем деструктора. Но собственно, POD имеет и другие ограничения, так что ясно, что деструктор у него — тривиальный, который как говорит стандарт ... implicitly-declared.

Спасибо, Шахтер уже процитировал, сам я отчего не нашел в стандарте — плохо еще ориентируюсь

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

S>>>Чем может грозить такое удаление( без вызова деструктора ) POD?

E>>Тем, что фрагмент кода внизу ill-formed и может не скомпилироваться.

S>Вы имеете в виду reinterpret_cast ?

Нет, я имею в виду нигде не определенный идентификатор __cdecl. Если его попросту убрать, то код будет well-formed. Но будет иметь undefined behavior. А вот как раз использование static_cast здесь единственно возможное, если его заменить на reinterpret_cast, код опять-таки будет ill-formed.

S>>>    std::list< Foo* >        lst;

S>>>    lst.push_back( new Foo );

S>>>    std::for_each(
S>>>            lst.begin(),
S>>>            lst.end(),
S>>>            static_cast< void(__cdecl*)(void*) >( ::operator delete )
S>>>        );

А если смотреть не на этот конкретный код, а по сути исходного вопроса, позволяет ли стандарт писать так operator delete(ptr) если где-то был ptr = new POD ?

On Fri, 18 Nov 2005 12:54:36 -0000, srggal <21794@users.rsdn.ru> wrote:

> Чем может грозить такое удаление( без вызова деструктора ) POD?
>
>

>     std::list< Foo* >        lst;
>
>     lst.push_back( new Foo );
>
>     std::for_each(
>             lst.begin(),
>             lst.end(),
>             static_cast< void(__cdecl*)(void*) >( ::operator delete )
>         );
>

А ты посмотри на вопрос под другим углом: выделяй POD стр-ру malloc(), освобождай free(). Другими словами, для POD-типов тебе не нужен дополнительный функционал new для вызова к-тора, delete для вызова д-тора.

Нет ненужного функционала, нет вопроса.

--
Maxim Yegorushkin

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

т.е.
>если где-то был ptr = new PODSTRUCT ?

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


ME>А ты посмотри на вопрос под другим углом: выделяй POD стр-ру malloc(), освобождай free(). Другими словами, для POD-типов тебе не нужен дополнительный функционал new для вызова к-тора, delete для вызова д-тора.

ME>Нет ненужного функционала, нет вопроса.



Но вопрос не мой, мне коллега задал вопрос, а можно ли обойтись в приведенной мной ситуации без самописного функтора, в его коде использовался new.

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


S>>Вы имеете в виду reinterpret_cast ?

E>Нет, я имею в виду нигде не определенный идентификатор __cdecl. Если его попросту убрать, то код будет well-formed. Но будет иметь undefined behavior. А вот как раз использование static_cast здесь единственно возможное, если его заменить на reinterpret_cast, код опять-таки будет ill-formed.

Спасибо, уже сообразил, просто мне __cdecl уже как родной, последнее время исключительно под виндами и MSVC.

А почему undefined behavior?
Что-то я запутался

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


Ш>Если деструктор у класса тривиальный, его можно не вызывать, а просто освободить память. Это относится как к POD типам, так и к болеее широкому класссу типов с тривиальным деструктором.

А вектор POD-ов? Вроде бы на эту тему не понятно что гарантируется.

интересен так же и другой момент, а можно ли вызывать тривиальный деструктор несколько раз?

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

L_L>А если смотреть не на этот конкретный код, а по сути исходного вопроса, позволяет ли стандарт писать так operator delete(ptr) если где-то был ptr = new POD ?

В общем случае — нет.

#include <cstddef>

void* buffer;

struct POD
{
    void* operator new(std::size_t)
    {
        return buffer;
    }
    void operator delete(void*) {}
};

int main()
{
    buffer = operator new(sizeof(POD));

    POD* ptr = new POD;
    operator delete(ptr);

    operator delete(buffer);
}

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

Sorry, увлекся тем, чтобы сделать компилируемый пример, и получилось не очень хорошо. Имелось в виду использовать какой-то альтернативный механизм распределения памяти, чтобы падал еще первый operator delete.

Ну, в общем, Вы поняли.

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

S>А почему undefined behavior?

Потому что находящиеся в стандартном контейнере объекты должны быть CopyConstructible и Assignable. А получившееся там после освобождения памяти indeterminate value перестает удовлетворять этим требованиям.

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

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

E>Sorry, увлекся тем, чтобы сделать компилируемый пример, и получилось не очень хорошо. Имелось в виду использовать какой-то альтернативный механизм распределения памяти, чтобы падал еще первый operator delete.

E>Ну, в общем, Вы поняли.

Не совсем но при чем тут падение

Я думал о варианте с выделением через каой-нить специфический аллокатор с последующим штатным operator delete