Бросать исключения C ++ через границы DLL

Question

Я читал разные вещи о том, как не следует выделять кучу памяти в одной DLL и освобождать ее извне этой DLL.Но как насчет создания объекта исключения, который является просто временным (как и большинство объектов исключения)?Например:

throw my_exception( args ); // temporary: no heap allocation

Когда объект исключения перехватывается за пределами DLL, деструктор для этого объекта в конечном итоге будет выполнен и память для объекта, не относящаяся к куче, будет освобождена.Это нормально, так как это не куча памяти?

Answer 1

Пересылка исключений C ++ через границы DLL возможна только тогда, когда все модули используют одну и ту же среду выполнения C ++, и в этом случае они также совместно используют кучу.Но это может быть бременем на обслуживание, особенно когда задействованы библиотеки от разных поставщиков, поэтому это не рекомендуется.

Если вы хотите обрабатывать ошибки, которые переносимы между несколькими версиями компиляторов / версий компиляторов / настройками компилятора, либо используйте returnкоды или предоставляемые ОС исключения (например, SEH в Windows) /

Answer 2

Это зависит от того, как была выделена эта память и используется ли механизм для ее выполнения («среда выполнения» или «диспетчер памяти») между конкретной DLL и другими частями приложения. Например. throw new my_exception( args ); также может быть в порядке в зависимости от деталей.

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

Использование IMalloc (см. MSDN) для размещения и размещения экземпляров new было бы другим способом (вызов OleInitialize раньше) ...

Действительно, распределение памяти является проблемой в зависимости от того, что используется. Например, смешивание статически связанных CRT и динамически связанных CRT в разных частях приложения приведет к таким же проблемам, что и код отладки и выпуска микширования. Проблема здесь в том, что код, который должен освободить память, использует другой «менеджер памяти». Но если брошенный объект знает о своем собственном уничтожении, все должно быть в порядке, поскольку код dtor будет находиться в том же модуле компиляции, что и тот, который его выделяет.