Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5

Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5
From: Billy O'Neal (VC LIBS) (bion_at_[hidden])
Date: 2016-10-10 11:28:08

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

Feedback from customers was that breaking bincompat every year was too rapid. We don't want to get into maintaining a bunch of separate forks. We are still maintaining, providing bugfixes for, and adding new features (like <variant>, <any>, <string_view>) to 140; 150 is not yet ready to ship.

>If Microsoft chooses not to support those extension codecvt facets, please
consider open sourcing them so users can make the fixes.

This is complicated because we don't own it -- there's licensing stuff that needs to be hashed out with Dinkumware before we would be able to do something like that.

Billy3
________________________________
From: Boost <boost-bounces_at_[hidden]> on behalf of Beman Dawes <bdawes_at_[hidden]>
Sent: Saturday, October 8, 2016 4:12:57 AM
To: Boost Developers List
Cc: Steve Wishnousky
Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5

On Sat, Oct 8, 2016 at 1:47 AM, Billy O'Neal (VC LIBS) <bion_at_[hidden]>
wrote:

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

_______________________________________________
Unsubscribe & other changes: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&data=01%7C01%7Cbion%40microsoft.com%7C7380e04b869e4111f8f308d3ef6c2b58%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=gVlCdJoW211xK2QEBvgcRfnvCdkXFa6vIvjhNf9AEWA%3D&reserved=0