Subject: Re: [boost] [filesystem] temp_directory_path() behavior on Windows
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-02-19 21:12:46
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
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk