On 18/02/2015 01:56, Niall Douglas wrote:
On 17 Feb 2015 at 9:38, Olaf van der Spek wrote:
Have the problems with mixing binaries compiled against the DLL with others compiled against the static lib been fixed in the new refactor?
AFAIK DLLs should always use the DLL CRT.
Agreed. But it's a tragedy of the commons - it takes just one vendor to not do that in their proprietary shipped DLLs.
I'm not sure why that would be a problem. If they ship a DLL linked statically then by definition they are not allowed to use anything from the CRT in their API. If *you* ship a DLL linked statically then *you're* not allowed to use anything from the CRT in your API. If you do want to use the CRT in your API then you are obligated to do one of the following: 1. ship the source to your library so that the application author can compile it against the CRT and compiler of their choice. 2. compile it in-house against *all* of the CRTs that you are expecting the application authors to be using, and then ship all of those binaries. As an application author, you need to make sure that if you are using compiler X with CRT Y that the component vendor either is going to give you the source or includes that exact combination (including version matches) as one of their build outputs. Otherwise you either persuade them to include it or you go look for another component. This is why most components either only use C API or COM API (because those have stable ABIs), or only support specific versions of Visual Studio (and occasionally a limited set of other popular compilers).
I also look forward to when WinClang is good enough that I can ship my MSVC compatible DLL which was linked against libstdc++, you can ship yours linked against libc++, and all that is somehow supposed to work without incident against DLLs linked with Dinkumware. Yay ....
I'm not convinced there will be a stable C++ ABI within my lifetime. (And yes, I know there are efforts going on to create one, but I'm not convinced that such a thing is even possible, let alone desirable.) C++'s type system is far too low-level for its own good in this regard.