интерфейс между exe и dll с другой библиотекой времени выполнения C/C++

Данный :исполняемый файл использует dll. У них разная среда выполнения c/c++. Какие ограничения существуют в интерфейсе между ними? Кроме того, они используют один и тот же компилятор, одну и ту же версию Boost (, но разные предварительно скомпилированные библиотеки boost ).

Я понимаю, что разные среды выполнения могут иметь разные кучи. Таким образом, удаление должно соответствовать новому из той же кучи.

Самое главное, что мы не можем передавать через интерфейс объекты STL, потому что, когда мы собираем exe-объекты STL, они связаны с одной средой выполнения. и при сборке dll тот же объект (, если мы передадим его по ссылке или скопируем через интерфейс ), будет связан с другой средой выполнения. И другая среда выполнения может иметь другую реализацию этого объекта.

Рассмотрим случаи:

1. Я думаю, что следующее безопасно. Dll экспортирует функцию, которая имеет ссылку параметра :на экспортированный пользовательский класс, который содержит частный класс STL в качестве члена. Dll выделяет память для этого объекта. Exe вызывает метод Release этого объекта, когда нужно его удалить.

2. Я думаю, что следующее НЕ безопасно.Определяемый пользователем класс создается в exe и передается через интерфейс exe/dll. Этот класс содержит частный класс STL в качестве члена. exe и dll совместно используют заголовки/файлы реализации этого пользовательского класса. Когда этот класс создается в отдельных проектах, будут использоваться разные реализации STL. Например, другая реализация строки ::размера()(из разных сред выполнения )будут применены к одному и тому же объекту в памяти.

3. Я думаю, что следующее безопасно. Определяемый пользователем класс создается в exe и передается через интерфейс exe/dll. Этот класс не зависит от стандартной библиотеки, он использует только примитивные типы C++. exe и dll совместно используют заголовки/файлы реализации этого пользовательского класса. Также мы должны контролировать, чтобы new и delete соответствовали одной и той же куче. Например, мы можем перегрузить new/delete, чтобы они использовали ::GetProcessHeap.

4. Я думаю, что следующее НЕ безопасно :передавать объекты boost через интерфейс exe/dll, потому что они могут зависеть от классов стандартной библиотеки. Также удаление может не соответствовать новой куче.

5. Я думаю, что следующее НЕ безопасно :, даже если мы передаем объекты boost через интерфейс exe/dll, и они не зависят от классов стандартной библиотеки, но не реализуются только как заголовок -, чем объект может быть создан с помощью одной библиотеки boost (для одной среды выполнения )и используется с другой библиотекой повышения (для другой среды выполнения ). Также удаление может не соответствовать новой куче.

Также я хочу использовать некую разновидность интеллектуального указателя для передачи ссылки на объекты (, упомянутые в пункте 3 ), из exe в dll и из dll в exe. Я думаю, что этот интеллектуальный указатель также должен перегружать new/delete для выделения счетчика ссылок из кучи процесса по умолчанию. Когда он попытается удалить указанный объект, он вызовет удаление перегруженного этим объектом (как в item3)

Для объектов из пункта 1 я хочу использовать собственный интеллектуальный указатель, который будет вызывать метод выпуска указанного объекта. (as boost ::общий _ptr с пользовательским выпуском)

Какие проблемы не были упомянуты? Поправьте меня пожалуйста.