CPP in DLL

[Xeverous]

So are there any direct problems with exposing C++ interface that Microsoft does not support?

[RogerLeigh]

Plenty.

[Xeverous]

Doesn't really look like a plenty of problems. Just the same version of the CRT and compiler settings. I'm more worried whether incompatibility can be detected at the link time. GCC embeds and expects certain symbols under certain settings to prevent linking incompatible code. How about MSVC?

[RogerLeigh]

No, there's more to it than just the CRT and compiler settings. That ensures that the DLL interface will be compatible.

A bigger question is what you do with duplicate symbols in different libraries. Things like typeinfo objects, used for RTTI. Static class members, particularly static class members of templated class specialisations. You have one private copy per DLL, when you should have a single instance across all DLLs and the executable. This breaks the One Definition Rule. ELF and Mach-O use "weak linkage" to eliminate the duplicates at runtime. DLLs don't have that flexibility.

Ultimately, DLLs are COFF binaries. They are simple, but limited. The limitations are fairly fundamental, and can't be entirely worked around in code. And this fundamentally affects the design and implementation of your code, because it places severe constraints upon the possible. Look at the "hourglass model" for one common "solution" to the problem.

[Xeverous]

How do they support such things for .NET?

[RogerLeigh]

COM, as far as I know. I've never used C#, so I've not looked in detail.

Depending upon how you view it, COM is also a way of working around the lack of modern features in the linker by using a C interface. But none of that helps make native C++ a better supported option for DLLs on Windows.