Re: [boost] [filesystem] temp_directory_path() behavior on Windows

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
>>> 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.