Вопрос не по Qt, а по переопределнным new и delete — поэтому сюда

У меня есть сторонный графический движок — я его прикрутил к своей проге на Qt как виджет на уровне исходников (не как сторонняя либа). Так вот — в этом графичесом движке переопределны операторы new и delete

И вот в какой-то момент стало падать на operator delete из этого движка, причем этот опретор вызывается из деструктора QList. А падает потому, что этот двигловый delete говорит, что память выделена не через его new.

Вот и вопрос по С++ — как разрулить-то? Как сделать, что если юзается не мой new, то и delete не мой надо юзать?

А>У меня есть сторонный графический движок — я его прикрутил к своей проге на Qt как виджет на уровне исходников (не как сторонняя либа). Так вот — в этом графичесом движке переопределны операторы new и delete

А>И вот в какой-то момент стало падать на operator delete из этого движка, причем этот опретор вызывается из деструктора QList. А падает потому, что этот двигловый delete говорит, что память выделена не через его new.

А>Вот и вопрос по С++ — как разрулить-то? Как сделать, что если юзается не мой new, то и delete не мой надо юзать?

Выкинуть из графического движка переопределения new / delete.
Это очень плохой дизайн либы — либа должна работать с тем менеджером, который ей подсунет программист, а не навязывать свой.
Возможно, кривизна еще и в самом переопределении -- как минимум, у меня несколько лет с разными версиями Qt жил свой менежер памяти, и она ни разу на это не обижалась
Например, забыли переопределить вариант с nothrow_t или еще что-нибудь.

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

K13>Выкинуть из графического движка переопределения new / delete.
K13>Это очень плохой дизайн либы — либа должна работать с тем менеджером, который ей подсунет программист, а не навязывать свой.
K13>Возможно, кривизна еще и в самом переопределении -- как минимум, у меня несколько лет с разными версиями Qt жил свой менежер памяти, и она ни разу на это не обижалась
K13>Например, забыли переопределить вариант с nothrow_t или еще что-нибудь.

То есть не может быть такого что new берется откуда-то из недр Qt, а delete на этот объект мой — переопределенный?

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

А>И вот в какой-то момент стало падать на operator delete из этого движка, причем этот опретор вызывается из деструктора QList. А падает потому, что этот двигловый delete говорит, что память выделена не через его new.

А поискать, кто именно и где именно создаёт объект?


Ещё может быть такая фигня, что у базового класса невиртуальный деструктор, а у наследованного — собственные операторы new/delete.
Тогда delete (Base*) new Derived() приведёт к трагедии:
— невызов деструктора Derived (это уже само по себе UB)
— вызов Base::operator delete (или глобального) — поскольку именно деструктор отвечает за вызов правильного оператора, см.выше (а вот и плоды этого UB)



А>Вот и вопрос по С++ — как разрулить-то? Как сделать, что если юзается не мой new, то и delete не мой надо юзать?

boost::shared_ptr<Base> вместе с указателем на объект Derived* запоминает и функцию удаления (по умолчанию — это checked_delete<Derived> в данном модуле).
Это позволяет безболезненно передавать указатели через границы DLL со статически прилинкованными персональными менеджерами памяти.

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

А>У меня есть сторонный графический движок — я его прикрутил к своей проге на Qt как виджет на уровне исходников (не как сторонняя либа). Так вот — в этом графичесом движке переопределны операторы new и delete

Кошмар! Глобально переопределять new — это полное ламерство. Надо лечитиь движок.

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

MS>Кошмар! Глобально переопределять new — это полное ламерство. Надо лечитиь движок.

Да нет, не движок кривой, а Qt — выделяет память через malloc, а удаляет через delete

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

А>Да нет, не движок кривой, а Qt — выделяет память через malloc, а удаляет через delete

Ересь! покажите где они это делают?