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

не согласен, на мой взгляд, обойтись малой кровью — это как раз переопределить операторы,

я это сделал так:
определил в исходном проекте (exe) 2 функции типа my_malloc и my_free, которые вызывают, соответственно malloc и free, экспортировал их,
а во всех подключаемых модулях, при загрузке на DLL_PROCESS_ATTACH импортиртирую их динамически из основного модуля ( ::GetProcAddress( NULL, ... ) ),
и в операторах их вызываю,

т.е. выходит так, что CRT хоть и инициирует свою кучу (_crtheap) в каждом модуле,
но STL использует только ту, что создается в главном (exe)

omb>а во всех подключаемых модулях, при загрузке на DLL_PROCESS_ATTACH импортиртирую их динамически из основного модуля ( ::GetProcAddress( NULL, ... ) ),
учите, что CRT'шый DllMain(..DLL_PROCESS_ATTACH...) отрабатывает после конструкторов глобальных объектов этих модулей

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

omb>>а во всех подключаемых модулях, при загрузке на DLL_PROCESS_ATTACH импортиртирую их динамически из основного модуля ( ::GetProcAddress( NULL, ... ) ),
O>учите, что CRT'шый DllMain(..DLL_PROCESS_ATTACH...) отрабатывает после конструкторов глобальных объектов этих модулей

конечно, что касается глобальных переменных, здесь вы правы,
хотя в любой момент можно инкапсулировать _DllMainCRTStartup, переопределив точку входа,
и импортировать все необходимое еще до вызова _CRT_INIT (этот уже особенности реализации dll)

в моем случае, все статическое находится в одном модуле (exe),
плагины просто добавляют функционал, а сами CRT и STL ничего подобного не делают до DllMain,
поэтому, лично у меня STL начинает работать с DLL_PROCESS_ATTACH