[C++] Перегрузка new и delete в производном классе

никогда не перегружай new и delete, если нужна кастомная стратегия выделения/освобождения памяти - используй аллокаторы/деаллокаторы

> никогда не перегружай new и delete

А подробнее/со ссылками можно пояснить, чем плохо перегружать new и delete?

> А подробнее/со ссылками можно пояснить, чем плохо перегружать new и delete?

возможны проблемы с библиотеками и конфликтом разных new/delete в рамках одного приложения

А подробнее/со ссылками можно пояснить, чем плохо перегружать new и delete?

1. см. сюда
2. плохо, как минимум то, что не очевидна семантика использования, человек использует стандартный синтаксис и надеется на стандартное поведение на текущей платформе, а в результате получает непонятное поведение, именно поэтому, к примеру, не рекомендуется лишний раз перегружать operator+ и т.д.

> никогда не перегружай new и delete, если нужна кастомная стратегия выделения/освобождения памяти - используй аллокаторы/деаллокаторы

Спасибо, но вопрос не совсем о том, как правильно писать программы.

Они и перегружаются для конкретного типа. Деструктор виртуален, значит всё нормально, вызовется нужный delete. В чём собственно вопрос?

> Деструктор виртуален, значит всё нормально, вызовется нужный delete

ммм... и давно вызов деструктора в C++ начал освобождать память?

> В чём собственно вопрос?

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

>ммм... и давно вызов деструктора в C++ начал освобождать память?

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

> При вызове оператора delete, деструктор определяет какому классу принадлежит это оператор delete, соответственно если не определить деструктор виртуальным, то он может промахнуться.

Судя по всему, так и происходит. Я, честно говоря, сначала подумал, что это какие-то сайд-эффекты оптимизации компилятора, т.к. приведенный пример слишком простой. Гугл не помог, читать стандарт было лень, поэтому эмпирически проверил кейс в более реалистичной ситуации с динамическими библиотеками и без инлайнов на разных компиляторах :) Так же, как ты и сказал, при не виртуальном деструкторе корректного вызова delete не происходит.

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

возможность реализовать пулирование для объектов, логика владения которыми лежит вне области кода, расширяющего предоставляемые извне классы (фреймворк какой-нибудь)

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

чувак ты предлагаешь какую-то ересь как мне кажется, ну или чуднО формулируешь свои мысли

Чувак, надеюсь, так будет понятнее (сорри, компиляцию не проверял):

#include <QCoreApplication>
#include <QEvent>
#include <QtDebug>

// Custom event class
class Event: public QEvent
{
public:
    Event ();
    ~Event ();
    
    void* operator new (size_t size);
    void operator delete (void *p);
};

Event::Event () :
    QEvent(QEvent::User)
{
    qDebug() << "ctor";
}

Event::~Event ()
{
    qDebug() << "dtor";
}

void* Event::operator new (size_t size)
{
    qDebug() << "new";
    
    // TODO: Use events pool here
    return malloc(size);
}

void Event::operator delete (void *p)
{
    qDebug() << "free";

    // TODO: Use events pool here    
    free(p);
}

// Object receiving custom events
class Receiver: public QObject
{
public:
    explicit Receiver (QObject *parent = 0);

    // QObject
    virtual bool event (QEvent *event);
};

Receiver::Receiver (QObject *parent) :
    QObject(parent)
{
}
        
bool Receiver::event (QEvent *event)
{
    if (event->type() == QEvent::User)
    {
        qDebug() << "event";

        QCoreApplication::instance()->quit();
        
        return true;
    }
    else
        return QObject::event(event);
};

int main (int argc, char* argv[])
{
    QCoreApplication app(argc, argv);

    // Allocating and posting event to receiver (event object will be destroyed by event loop once delivered and processed)
    Receiver recv;
    app.postEvent(&recv, new Event);

    // Entering event loop
    return app.exec();
}

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

Ну так и надо писать свой new так, чтобы он вписывался в стандартную семантику и вёл себя так, как велит стандарт.

Ну так и надо писать свой new так, чтобы он вписывался в стандартную семантику и вёл себя так, как велит стандарт.

тогда вообще зачем его писать, такой new уже есть

некогда вдумчиво парсить, но имхо - трава

> тогда вообще зачем его писать, такой new уже есть

В большинстве случаев так и есть :) Тот же пул объектов вполне можно реализовать через перегрузку new/delete.

> Тот же пул объектов вполне можно реализовать через перегрузку new/delete.

Ну да, товарищ выше уже написал эту идею.

Тот же пул объектов вполне можно реализовать через перегрузку new/delete.

ну вот так через аксессор для клизьмы делают, а потом говорят, что С++ кривой

> некогда вдумчиво парсить, но имхо - трава

согласен, сп**дануть «юзай аллокаторы», «ты желаешь странного» и «ты еще Qt не видел» гораздо проще

> ну вот так через аксессор для клизьмы делают, а потом говорят, что С++ кривой

Никто не говорит, что перегруз new/delete для пула объектов - лучший путь. Но в некоторых ситуациях по-другому не сделать (см. пример выше).