Проблемы, связанные с переопределением глобальных операторов new и delete

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

Сейчас пишу диспетчер памяти. Я рассматриваю возможность переопределения операторов global new и delete для оптимизации всего приложения. Внутри настраиваемого диспетчера памяти используются те же самые старые операторы new и delete (для выделения больших фрагментов памяти по мере необходимости во время выполнения и выделения их частей для фактического использования в моем программном обеспечении).

  • Могут ли у меня быть проблемы с этим подходом? Я хочу использовать в своем приложении множество библиотек, таких как DirectX, STL и Boost.
  • Могут ли те слухи, которые я упомянул в первом абзаце, быть правдой?

Я использую VS2010

-- РЕДАКТИРОВАТЬ --

Я должен использовать malloc () и free () внутри ритуала MemoryManager.


person Deamonpog    schedule 21.02.2015    source источник
comment
Другой способ переопределить часть подсистемы распределения памяти - написать распределитель, который вы предоставляете всем контейнерам.   -  person Some programmer dude    schedule 21.02.2015
comment
Вам следует прочитать этот ответ: stackoverflow.com/a/22039345/1413395   -  person πάντα ῥεῖ    schedule 21.02.2015


Ответы (1)


Если вы собираетесь переопределить глобальное new / delete, лучше использовать хорошо протестированные и производительные библиотеки:

Причина в том, что эти библиотеки в общем случае будут лучше, чем все, что вы можете написать (меньше ошибок, больше производительности и т. Д.). Если вам нужно конкретное распределение для очень конкретных случаев (выделение стека, пул), вы должны сделать свой код расширяемым с помощью настраиваемого распределителя, который пользователь может изменить (легко, если пользователь может получить доступ и перекомпилировать ваш исходный код, иначе вы должны предоставить какой-то вид интерфейс).

Обратите внимание, что контейнеры STL используют настраиваемые распределители, поэтому вы можете улучшить / снизить их производительность, просто изменив распределитель:

C ++ 11 способ:

namespace myspace{
    template< typename T>
    using myVector = std::vector<T, yourAllocator<T>>;
}

//usage
myspace::myVector vec;

Старый способ:

namespace myspace{
    template<typename T>
    struct myVector{
        typedef std::vector<T, yourAllocator<T>> type;
    };
}

//usage
myspace::myVector::type vec;

Если вы действительно хотите переопределить глобальное новое / удалить, все, что вам нужно, это скомпилировать свою собственную версию new / delete (конечно, вы должны использовать некоторую библиотеку malloc / malloc) и связать ее с вашим исполняемым файлом как последний (ну, я думаю, порядок не имеет значения, если только кто-то другой не отменяет и эти операторы).

Проблемы:

В Windows вы не можете переопределить глобальное создание / удаление для библиотек DLL, связывание которых вы не можете контролировать. Вернитесь и прочтите еще раз. Если вы не можете перекомпилировать / повторно связать DLL, вы не можете переопределить выделение памяти, что означает, что вы должны проявлять осторожность при использовании DLL. Обычно это не проблема, если только вы не пытаетесь удалить что-то, созданное DLL, с помощью собственного удаления. Для системных DLL это не проблема (вы можете создавать объекты / дескрипторы только с помощью системных функций, а вы можете уничтожать объекты / дескрипторы только с помощью системных функций)

Я просто задаю вам вопрос, и я дам вам ответ: если у вас есть класс, этот класс компилируется в DLL (в Windows), вам действительно нужно беспокоиться, если вы создаете подкласс со своим пользовательским new / delete а затем вы создаете собственный экземпляр этого класса?

class DLLEXPORT AClass{
//stuff
//...
};

ваш код

class MyClass: public AClass{

};

or

class MyClass: public virtual AClass{

};

.

//inside your program
AClass * a = new AClass;
MyClass * m = new MyClass;
person CoffeDeveloper    schedule 21.02.2015