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

_>>Делайте классическим способом:
C>В конце прошлого века я сам такое всем советовал.
Так в C++ добавили дофига всякого не нужного хлама, а вот для работы с динамическими библиотеками руки пачкать не хотят.

C>Различие в менеджерах памяти неважно, если право владения указателями (в т.ч. в составе объектов, таких как std::vector) не будет предаваться за пределы dll.
Самый оптимальный вариант с интерфейсами.

C>У меня не передается, поскольку конструкторы/деструкторы/оператор= — экспортируются, а доступа к приватным членам нет, в том числе со стороны членов класса, генерируемых компилятором (потому что их нет).
В интерфейсах вообще ни слова о приватных полях, только публичные методы.

C>Из опасностей остается:
C>1) различие в выравнивании (если в классе несколько членов),
C>2) различение в реализации передаваемых объектов (std::vector может хранить два указателя, а может указатель и длину, или длина будет храниться в блоке под указателем,... )
C>3) Передаваемые объекты не должны содержать inline (или генерируемых компилятором) членов, которые вызывали бы функции C-runtime или C++-runtime, который действительно может измениться. Это было бы нарушением ODR.
Всё это хорошо скрывается интерфейсами. В том числе и выравнивание, и исключения ныкаются через HRESULT.

C>Собственно п.(2) и (3) не позволяют передавать объекты стандартной библиотеки под windows. (Под linux проблемы нет, но мне нужны обе платформы.)
Вы можете и из под виндовс иметь общий runtime если будете стандартную билиотеку динамически линковать. Но это будет квази динамическая библиотека, она будет прибита к версии рунтайма гвоздями. Т.е. если это плагин то он должен собираться строго с той же версией стандартных dll иначе не загружаться или же просто рассыпаться.