On Fri, Oct 7, 2016 at 8:51 PM, Billy O'Neal (VC LIBS) wrote:

I believe we have a couple of bugs with char16_t / char32_t things. :(

I recently reported a bug with char32_t instantiations in one of the extension codecvt headers (big5 IIRC) and would not be surprised if the same problem applies to char16_t and to <codecvt>. But it was easy to workaround - just instantiate with uint32_t (which works OK) and then before calls cast the char32_t pointers to uint32_t pointers. A hack, but I was just using it in some test code. --Beman

Billy3 ________________________________ From: Boost on behalf of Andrey Semashev < andrey.semashev@gmail.com> Sent: Friday, October 7, 2016 5:49:27 PM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5

On 10/08/16 00:38, Beman Dawes wrote:

...

BOOST_NO_CXX11_HDR_CODECVT

That's wrong. <codecvt> has been supplied at least since msvc 10.0. I'll submit a P/R.

I remember the <codecvt> functionality was unusable because of the linking errors. I think it was the case around MSVC 14. I don't know if/when it was fixed.

_______________________________________________ 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% 7C0a8ccbdc7f5d43508e4708d3ef150751%7C72f988bf86f141af91ab2d7cd011 db47%7C1&sdata=L%2BDIjAELdJd3M1Iy2IBmvpqEU6m8dg g4oYxlvl%2FwqDc%3D&reserved=0

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

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)

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 ;) Billy3 ________________________________ From: Boost on behalf of Marcel Raad Sent: Friday, October 7, 2016 9:25:02 PM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5 Andrey Semashev-2 wrote

On 10/08/16 00:38, Beman Dawes wrote:

...

BOOST_NO_CXX11_HDR_CODECVT

That's wrong.

<codecvt> has been supplied at least since msvc 10.0. I'll

...

submit a P/R.

I remember the <codecvt> functionality was unusable because of the linking errors. I think it was the case around MSVC 14. I don't know if/when it was fixed.

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: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconnect.microsoft.com%2FVisualStudio%2Ffeedback%2Fdetails%2F1348277%2F&data=01%7C01%7Cbion%40microsoft.com%7Cc3e46ec2feb048fa36b708d3ef340e85%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=c3YqOtKC8OoSzhE1l9vzLbJ%2Fv2nTM81fXEfK%2B9JSa6c%3D&reserved=0 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconnect.microsoft.com%2FVisualStudio%2Ffeedback%2Fdetails%2F1403302%2F&data=01%7C01%7Cbion%40microsoft.com%7Cc3e46ec2feb048fa36b708d3ef340e85%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=TYYALS5DIETi22OTiyU1eai5RUIEqnRbaVr48USM0Qk%3D&reserved=0 -- View this message in context: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fboost.2283326.n4.nabble.com%2Fconfig-Changes-to-reflect-Visual-C-15-preview-5-tp4688677p4688684.html&data=01%7C01%7Cbion%40microsoft.com%7Cc3e46ec2feb048fa36b708d3ef340e85%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=iufFNh0FrXmBObqfNtPi9an69tCRE1LLMRd6JMpxucQ%3D&reserved=0 Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ 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%7Cc3e46ec2feb048fa36b708d3ef340e85%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=L4kHSS4MWf%2Ftt0SF%2BXZwPeVsO%2FXNrzhVr%2Fo4XyCIFnA%3D&reserved=0

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>, ) 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 on behalf of Beman Dawes 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) 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

Why adding export symbols for char16_t and char32_t is considered a breakage?

Because we support app-local deployment of P, we can't change its export surface in any way without breaking bincompat. Consider the following scenario: 1. A printer driver or similar application is installed using the "new" msvcp140.dll using the vc redist for Visual Studio "15". 2. An application is installed which uses a previous copy of msvcp140.dll, such as that shipping now with Visual Studio 2015 RTM. 3. Application starts, and user edits a document. 4. User tries to print. This attempts to load the print driver into the application's process. 5. The print driver looks for the new exports in msvcp140.dll, but the application's app-local copy, not the one installed by the redist, is already loaded into the process. 6. Print driver DLL can't find the new exports its looking for, and the program crashes. This is why we tried very hard to kill support for app-local DLL deployment, so that we could add features and bugfixes the same way the operating system does e.g. for kernel32.dll, but that was received badly. (In that case, only the system copy of the DLL exists, and that one is maintained at the latest installed copy)

You could just make those symbols point to the unsigned short and unsigned int API implementation that you already provide and recommend using in the MS Connect tickets.

We may be able to inject something like this with an additional static library but have been reluctant to do so -- the presence of the bug in the shipping product indicates that there is a gap in understanding of how these extension codecvt facets were/are intended to operate, and/or that such functionality was never tested.

IMHO, this sort of bugs should have been fixed even before VC14 RTM, let alone the later updates.

Agreed [?] Billy3 ________________________________ From: Boost on behalf of Andrey Semashev Sent: Monday, October 10, 2016 9:23:05 AM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5 On 10/10/16 18:28, Billy O'Neal (VC LIBS) wrote:

...

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>, ) to 140; 150 is not yet ready to ship.

Why adding export symbols for char16_t and char32_t is considered a breakage? You could just make those symbols point to the unsigned short and unsigned int API implementation that you already provide and recommend using in the MS Connect tickets. IMHO, this sort of bugs should have been fixed even before VC14 RTM, let alone the later updates. _______________________________________________ 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%7C6e04e86bc94741ca7e3f08d3f129cb65%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=O1TfA7t3x4z6KMDq3OE3SQSeRxpCY9M%2BkVOADdI0hFU%3D&reserved=0

On Mon, Oct 10, 2016 at 5:28 PM, Billy O'Neal (VC LIBS) wrote:

Feedback from customers was that breaking bincompat every year was too rapid.

What's the problem for them? Most of the time there's two years between releases anyway and VS15 is unlikely to be released this year, so 2017 - 2015 > 1 ;)

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>, ) to 140; 150 is not yet ready to ship.

, at last :p On Mon, Oct 10, 2016 at 6:41 PM, Billy O'Neal (VC LIBS) wrote:

...

Why adding export symbols for char16_t and char32_t is considered a breakage?

2. An application is installed which uses a previous copy of msvcp140.dll, such as that shipping now with Visual Studio 2015 RTM.

Can't the newer global msvcp140.dll override this older local one?

This is why we tried very hard to kill support for app-local DLL deployment, so that we could add features and bugfixes the same way the operating system does e.g. for kernel32.dll, but that was received badly.

Don't kill stuff, offer users a better way to do it instead. Personally I link the runtime statically :p but if Windows could take care of installing the redist DLLs for me I'd use that instead. Of course, that'd have to work on W7 as well, not just W10.

From personal experience...we updated to Visual Studio 2015 recently and had to decide how to handle the deployment. We tried to do it the "right" way using vcredist from a bootstrapper. Then we just gave a customer an alpha and spent lots of time determining why it crashed on startup. It ended up being because vcredist didn't pull down ucrtbase.dll for some reason.

Remotely debugging windows updates on machines we may have no access to (and might be in secure environments) is not a burden we can take...so app-local is what we must do. Just an FYI Rob ________________________________ From: Boost on behalf of Billy O'Neal (VC LIBS) Sent: Tuesday, October 11, 2016 3:36:06 PM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5

Can't the newer global msvcp140.dll override this older local one?

Nope. The loader doesn't do version comparisons. (And even if we could convince Windows to change the loader to do that, there's no way they're going to backport such a change to all the platforms we support) Once a copy of that DLL is in the process further calls to LoadLibrary with the same DLL name return a reference to the already loaded copy. The search order the system uses is: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).a... 1. The directory from which the application loaded. 2. The system directory. Use the GetSystemDirectoryhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms724373(v=vs.85).a... function to get the path of this directory. 3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. 4. The Windows directory. Use the GetWindowsDirectoryhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms724454(v=vs.85).a... function to get the path of this directory. 5. The current directory. 6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path. So app-local "wins". We could KnownDll https://blogs.msdn.microsoft.com/larryosterman/2004/07/19/what-are-known-dll... the thing which would mean let the system version override the app-local version, but that breaks in the other direction -- older system DLL with newer app-local deployed copy would cause the app depending on the new exports to load the system32 one instead and fail due to missing exports.

Don't kill stuff, offer users a better way to do it instead.

We're open to suggestions :). We've been saying the "better way" is the redist, or static linking, for years.

Of course, that'd have to work on W7 as well, not just W10.

Even if the redist was bundled with the OS that still wouldn't help here, because Win7 shipped ~6 years before VS2015 :). Time machines and all that. Billy3 ________________________________ From: Boost on behalf of Olaf van der Spek Sent: Tuesday, October 11, 2016 12:24 PM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5 On Mon, Oct 10, 2016 at 5:28 PM, Billy O'Neal (VC LIBS) wrote:

Feedback from customers was that breaking bincompat every year was too rapid.

What's the problem for them? Most of the time there's two years between releases anyway and VS15 is unlikely to be released this year, so 2017 - 2015 > 1 ;)

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>, ) to 140; 150 is not yet ready to ship.

, at last :p On Mon, Oct 10, 2016 at 6:41 PM, Billy O'Neal (VC LIBS) wrote:

...

Why adding export symbols for char16_t and char32_t is considered a breakage?

2. An application is installed which uses a previous copy of msvcp140.dll, such as that shipping now with Visual Studio 2015 RTM.

Can't the newer global msvcp140.dll override this older local one?

This is why we tried very hard to kill support for app-local DLL deployment, so that we could add features and bugfixes the same way the operating system does e.g. for kernel32.dll, but that was received badly.

Don't kill stuff, offer users a better way to do it instead. Personally I link the runtime statically :p but if Windows could take care of installing the redist DLLs for me I'd use that instead. Of course, that'd have to work on W7 as well, not just W10. _______________________________________________ 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%7Cc1fa5d22f7bf45ee0a4008d3f20c4073%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=v%2F3MwTGvEi7Za6jZzgOH8%2FSbktz9U03n6Tr%2FpxCcoys%3D&reserved=0 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Is static preferred over app-local? I thought it was the other way around.

Static is preferred if it works for you. Unfortunately there are circumstances where you can't tolerate multiple CRTs in the same process because you need some global state to be synchronized, and in such cases the only option is to use the DLL.

Windows Update?

Windows Update deploys the UCRT, and you just said that wasn't OK for you :) Billy3 ________________________________ From: Boost on behalf of Olaf van der Spek Sent: Wednesday, October 12, 2016 12:09:01 AM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5 On Tue, Oct 11, 2016 at 9:36 PM, Billy O'Neal (VC LIBS) wrote:

...

Don't kill stuff, offer users a better way to do it instead.

We're open to suggestions :). We've been saying the "better way" is the redist, or static linking, for years.

Is static preferred over app-local? I thought it was the other way around.

...

Of course, that'd have to work on W7 as well, not just W10.

Even if the redist was bundled with the OS that still wouldn't help here, because Win7 shipped ~6 years before VS2015 :). Time machines and all that.

Windows Update? _______________________________________________ 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%7C517f6681051047593efb08d3f26eb001%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=X3TcMjrzlHxuWTqbsKq0OFJdzhpPjdaZlXYQefl3EPo%3D&reserved=0

If it doesn't already, then the VC redist needs to have a baseline UCRT that it deploys if there isn't already a newer one provided by Windows Update.

That is how it is supposed to work. If you're seeing otherwise we're interested in a bug report / repro steps. Billy3 ________________________________ From: Boost on behalf of Gavin Lambert Sent: Wednesday, October 12, 2016 3:19:14 PM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5 On 13/10/2016 06:31, Billy O'Neal (VC LIBS) wrote:

Windows Update deploys the UCRT, and you just said that wasn't OK for you :)

If it doesn't already, then the VC redist needs to have a baseline UCRT that it deploys if there isn't already a newer one provided by Windows Update. You can't have a redist that depends on something that isn't bundled with it or known to always already be present on the system. And some people disable updates, or they fail, or otherwise aren't installed in time. _______________________________________________ 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%7C4c541cf462e64977551308d3f2ede3fc%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=%2BVaYydKll2leOEeI%2Fy8ODMImTXyzgLaJlEWX6Rz67Rc%3D&reserved=0

I said it wasn't ok for me since I found it failed with a customer. I'm afraid I don't have the time to investigate and determine how to reproduce the issue, and I don't have access to the customers machine. Although some (probably) relevant information can be found here: http://stackoverflow.com/questions/34240852/stuck-while-installing-visual-st... Rob ________________________________ From: Boost on behalf of Olaf van der Spek Sent: Thursday, October 13, 2016 4:34:44 PM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5 On Wed, Oct 12, 2016 at 7:31 PM, Billy O'Neal (VC LIBS) wrote:

...

Is static preferred over app-local? I thought it was the other way around.

Static is preferred if it works for you. Unfortunately there are circumstances where you can't tolerate multiple CRTs in the same process because you need some global state to be synchronized, and in such cases the only option is to use the DLL.

...

Windows Update?

Windows Update deploys the UCRT, and you just said that wasn't OK for you :)

You lost me.. where did I say that was not OK for me? If WU takes care of that, I shouldn't need vcredist right? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

You lost me.. where did I say that was not OK for me? If WU takes care of that, I shouldn't need vcredist right? Sorry, I must have confused you with someone else earlier in this thread. The message as it shows up over here looks like it comes from "the boost mailing list", not from any individual person.

From my investigations it seems like the redist is able to install KB2999226 but only if KB2919442 and KB2919355 are already installed. Hmm... I looked at the internal copy of that bug and it says resolved as "fixed", but I don't see any changes that actually fix it. :/ If you see it continuing to happen with the Preview 5 redist, please let us know. My understanding is that things are intended to work on each of our supported target platforms if the target machine at least has the current service pack installed. (For example, Windows XP SP2 is not supported, only SP3)

Billy3 ________________________________ From: Boost on behalf of alanbirtles2 Sent: Friday, October 14, 2016 7:33:06 AM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5 There is a connect issue on this subject already at https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconnect.microsoft.com%2FVisualStudio%2Ffeedback%2Fdetails%2F1598704%2Fmicrosoft-visual-c-2015-redistributable-x86-and-x64-14-0-23026-fail-to-properly-install-on-windows-8-1-x64&data=01%7C01%7Cbion%40microsoft.com%7C613eb867e7de49426f5908d3f44176b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=%2FH2j00YpQEPEs3ewwiC4uKTqYJCxI0t%2BEDARttK8B60%3D&reserved=0.

From my investigations it seems like the redist is able to install KB2999226 but only if KB2919442 and KB2919355 are already installed.

-- View this message in context: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fboost.2283326.n4.nabble.com%2Fconfig-Changes-to-reflect-Visual-C-15-preview-5-tp4688677p4688887.html&data=01%7C01%7Cbion%40microsoft.com%7C613eb867e7de49426f5908d3f44176b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=DVHe7bM8xBjB2dQDkWLJxUxf1h7HB4tvRst2pT%2BZOGs%3D&reserved=0 Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ 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%7C613eb867e7de49426f5908d3f44176b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=zjD72hd7kGYUD6UawyrOeMwE1MLzcgRHd0BoUBWQylc%3D&reserved=0

I asked around internally like this and supposedly the setup folks are working on it. The error you're seeing is the error our redist gets -- we chainload the windows update installer that deploys the UCRT, and that error code is all we get back. (It's likely the "resolution" to this problem is going to be checking for the presence of this dependency and blocking the installer saying "you need XYZ service pack installed before attempting to install" or similar) Sorry about that :( Billy3 ________________________________ From: Boost on behalf of alanbirtles2 Sent: Wednesday, October 19, 2016 8:37:18 AM To: boost@lists.boost.org Subject: Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5 Billy O'Neal (VC LIBS) wrote

Hmm... I looked at the internal copy of that bug and it says resolved as "fixed", but I don't see any changes that actually fix it. :/ If you see it continuing to happen with the Preview 5 redist, please let us know. My understanding is that things are intended to work on each of our supported target platforms if the target machine at least has the current service pack installed. (For example, Windows XP SP2 is not supported, only SP3)

Yes the preview 5 redist fails to install in the same way on a clean copy of Windows 8.1, at a minimum it would be nice if the installer detected the missing updates and then directed the user to install them rather than failing with the cryptic "0x80240017 - Unspecified error" -- View this message in context: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fboost.2283326.n4.nabble.com%2Fconfig-Changes-to-reflect-Visual-C-15-preview-5-tp4688677p4689033.html&data=02%7C01%7Cbion%40microsoft.com%7C82f235eef38146288a0d08d3f83c6b6a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636124910787298258&sdata=76Qu378WkpY29WFP5o8C%2ByUBROtbejGID8uEulzG8AY%3D&reserved=0 Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&data=02%7C01%7Cbion%40microsoft.com%7C82f235eef38146288a0d08d3f83c6b6a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636124910787308271&sdata=kGl73IqhChYAYZTZPJthHfvP05dDZNy80lo0iWGFHQY%3D&reserved=0

On Sat, Oct 8, 2016 at 4:31 AM, Boris Rasin wrote:

On 2016-10-08 12:38 AM, Beman Dawes wrote:

...

BOOST_NO_CXX14_CONSTEXPR

The "15" preview 5 release notes say "The most notable compiler changes include complete support for generalized constexpr" I know from conversations with msft folks that they put a lot of effort into constexpr fixes, and that they would like bug reports if anyone is finds constexpr bugs with "15" preview 5. I'll submit a P/R.

Microsoft "Connect" is full of constexpr bug reports which are not getting fixed. Here are a few examples:

https://connect.microsoft.com/VisualStudio/feedback/details/ 2321214/constexpr-taking-address-of-static-object-error-c213 1-expression-did-not-evaluate-to-a-constant https://connect.microsoft.com/VisualStudio/feedback/details/ 2596275/c-constexpr-error-c2975 https://connect.microsoft.com/VisualStudio/feedback/details/ 2174854/constexpr-variables-always-have-internal-linkage

I asked the VC++ folks about those and Cody Miller, the dev who is working constexpr issues, replied:

I’ll prioritize fixes for the three issues called out below (I’m testing a fix for one of them right now).

Our goal is to be down to zero customer-reported issues in time for release, but if you know of any

issues that impact Boost and should be prioritized, please let me know.

Msft is now running the Boost regression tests as part of their release criteria for constexpr, expression sfinae, and perhaps some other worrisome areas. But if there are "Connect" issues that impact Boost, email me privately and I'll put you in touch with Cody so he can give them priority. --Beman