On Sat, Oct 8, 2016 at 1:47 AM, Billy O'Neal (VC LIBS)
This still applies to MSVC 14.3, you can see the errors in the lexical_cast tests. Unfortuntely the tests don't build with MSVC 15 Preview 5 because of the new directory structure. But the MS Connect reports have been resolved as fixed
It's fixed in WCFB02 -- next time we can break bincompat. VS "15" will not have this bug fixed, as it requires changing the export surface of MSVCP140.dll, which we cannot do since we support deploying that thing app-locally. (Steve's comment in the connect bug saying he fixed this in the "next major version" was from February, before the major release schedules of the libraries and Visual Studio proper were de-synchronized)
So this library/compiler decoupling has the consequence of delaying bug fixes users are waiting for. Shouldn't users be allowed to make the "break ABI" choice for themselves? I.E. supply both MSVCP140.dll and MSVCP150.dll with 140 the default initially, then 150 further down the road, then eventually no longer supply 140.
I recently reported a bug with char32_t instantiations in one of the extension codecvt headers (big5 IIRC)
Yes, I get to fix this bug. I'm not sure if any of those extensions are intended to be supported with char16_t/char32_t. Going to make for fun debugging ;)
Those extensions are a lifeline for users who have to deal with legacy encodings in old datasets. If they don't support char16_t/char32_t, then users can't modernize their code. If Microsoft chooses not to support those extension codecvt facets, please consider open sourcing them so users can make the fixes. Thanks, --Beman