Le 15.08.17 à 15:44, alanbirtles2 via Boost a écrit :

Boost - Dev mailing list wrote

...

What am I doing wrong?

Nothing, VC 2015 and 2017 share the same ABI and runtime libraries

Thanks! I did not know that. Raffi

[alanbirtles2]

VC 2015 and 2017 share the same ABI and runtime libraries

Correct. [Roger Leigh]

Note that it's conditionally true. VS2017 can use the v140 toolset from VS2015. But you can also choose to use the v141 toolset which is *not* compatible.

Incorrect. The complexity of our versioning story is admittedly a freight train colliding with a dumpster fire orbiting a supernova. Here's the simple form: * There are two IDEs, VS 2015 (which was updated several times) and VS 2017 (also updated several times so far). * Each IDE shipped with a corresponding toolset. VS 2015 shipped with toolset v140 (compiler 19.00) and VS 2017 RTM shipped with toolset v141 (compiler 19.10). * The VS 2017 IDE which ordinarily uses the v141 toolset has the ability to install and use the v140 toolset, without the VS 2015 IDE itself being installed. * From now on, I will mostly ignore the IDEs and focus on the toolsets (and I will try to be careful to use toolset/compiler versioning - through metonymy I usually refer to toolset versions by their corresponding IDE versions but that isn't a good idea here). * The v140 toolset (compiler 19.00) uses the Universal CRT in Windows (ucrtbase.dll) and additional DLLs that are part of the VCRedist: vcruntime140.dll, msvcp140.dll, etc. * We updated the v140 toolset a few times, fixing bugs and (notably) adding features. (These shipped alongside the VS 2015.1, 2015.2, and 2015.3 IDEs.) All updates were binary-compatible and updated the DLLs in-place. This was true even for major updates like fixing the dreaded iostreams floating-point performance regression. * The v141 toolset (compiler 19.10, originally) still uses ucrtbase.dll, vcruntime140.dll, msvcp140.dll, etc. It is binary-compatible with the v140 toolset, and objects/libs/DLLs can be intermixed freely. That said, it is still a good idea to compile everything consistently with the latest toolset so you receive all correctness/performance fixes, but mixing versions won't trigger crashes or other misbehavior. * We just updated the v141 toolset, which can be identified by its compiler version (the VS 2017 15.3 IDE update installs a new v141 toolset with compiler 19.11). Again, we've added new features while preserving bincompat. We're going to a LOT of trouble to preserve binary compatibility, so we hope it is useful. (We are having to be careful when updating the STL - any header change essentially triggers an ODR violation when object files are mixed-and-matched but there are innocuous ODR violations and poisonous ODR violations, and we know how to tell the difference.) STL