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

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Beman Dawes
Boost.Config is current reporting these macros for msvc 14.0 update 3 and
later:

BOOST_NO_COMPLETE_VALUE_INITIALIZATION

Xiang Fan of the VC++ compiler team kindly tested "15" preview 5 against
boost without this macro is still getting errors. So this one is still
needed.

BOOST_NO_CXX11_HDR_CODECVT

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

BOOST_NO_CXX14_AGGREGATE_NSDMI

Here is a test program, based on the config docs:

#include <cassert>

struct Foo
{
  int x, y = 42;
};

int main()
{
Foo foo = { 1234 };
assert(foo.y == 42);
assert(foo.x == 1234);
}

That now passed on "15" preview 5, so I'll summit a P/R.

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.

BOOST_NO_TWO_PHASE_NAME_LOOKUP

This one still applies. The backstory has changed a lot, however. Enough
progress has been made on the new parser that  two phase name lookup should
ship next year, and maybe even early next year. But don't hold your breath
quite yet.

Thanks to Andrew Pardoe for fact checking a draft of this post.

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
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: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Billy O'Neal (VC LIBS)
I believe we have a couple of bugs with char16_t / char32_t things. :(


Billy3
________________________________
From: Boost <[hidden email]> on behalf of Andrey Semashev <[hidden email]>
Sent: Friday, October 7, 2016 5:49:27 PM
To: [hidden email]
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%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=L%2BDIjAELdJd3M1Iy2IBmvpqEU6m8dgg4oYxlvl%2FwqDc%3D&reserved=0

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Beman Dawes
On Fri, Oct 7, 2016 at 8:51 PM, Billy O'Neal (VC LIBS) <[hidden email]>
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 <[hidden email]> on behalf of Andrey Semashev <
> [hidden email]>
> Sent: Friday, October 7, 2016 5:49:27 PM
> To: [hidden email]
> 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
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Marcel Raad
In reply to this post by Andrey Semashev-2
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://connect.microsoft.com/VisualStudio/feedback/details/1348277/
https://connect.microsoft.com/VisualStudio/feedback/details/1403302/
Reply | Threaded
Open this post in threaded view
|

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

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)


>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 <[hidden email]> on behalf of Marcel Raad <[hidden email]>
Sent: Friday, October 7, 2016 9:25:02 PM
To: [hidden email]
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boris Rasin
In reply to this post by Beman Dawes
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-c2131-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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Beman Dawes
In reply to this post by Billy O'Neal (VC LIBS)
On Sat, Oct 8, 2016 at 1:47 AM, Billy O'Neal (VC LIBS) <[hidden email]>
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: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Billy O'Neal (VC LIBS)
>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 <[hidden email]> on behalf of Beman Dawes <[hidden email]>
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) <[hidden email]>
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
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>, <string_view>) 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: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Billy O'Neal (VC LIBS)
>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 <[hidden email]> on behalf of Andrey Semashev <[hidden email]>
Sent: Monday, October 10, 2016 9:23:05 AM
To: [hidden email]
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>, <string_view>) 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Andrey Semashev-2
On 10/10/16 19:41, Billy O'Neal (VC LIBS) wrote:

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

I think it could be done without an additional static library. GCC
provides the alias attribute[1] which could be used for this purpose,
MSVC could have a similar attribute as well.

[1]:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Olaf van der Spek-3
In reply to this post by Billy O'Neal (VC LIBS)
On Mon, Oct 10, 2016 at 5:28 PM, Billy O'Neal (VC LIBS)
<[hidden email]> 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>, <string_view>) to 140; 150 is not yet ready to ship.

<string_view>, at last :p


On Mon, Oct 10, 2016 at 6:41 PM, Billy O'Neal (VC LIBS)
<[hidden email]> 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: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Billy O'Neal (VC LIBS)
>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).aspx#standard_search_order_for_desktop_applications


  1.  The directory from which the application loaded.
  2.  The system directory. Use the GetSystemDirectory<https://msdn.microsoft.com/en-us/library/windows/desktop/ms724373(v=vs.85).aspx> 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 GetWindowsDirectory<https://msdn.microsoft.com/en-us/library/windows/desktop/ms724454(v=vs.85).aspx> 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-dlls-anyway/> 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 <[hidden email]> on behalf of Olaf van der Spek <[hidden email]>
Sent: Tuesday, October 11, 2016 12:24 PM
To: [hidden email]
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)
<[hidden email]> 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>, <string_view>) to 140; 150 is not yet ready to ship.

<string_view>, at last :p


On Mon, Oct 10, 2016 at 6:41 PM, Billy O'Neal (VC LIBS)
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Rob Conde
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 <[hidden email]> on behalf of Billy O'Neal (VC LIBS) <[hidden email]>
Sent: Tuesday, October 11, 2016 3:36:06 PM
To: [hidden email]
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).aspx#standard_search_order_for_desktop_applications


  1.  The directory from which the application loaded.
  2.  The system directory. Use the GetSystemDirectory<https://msdn.microsoft.com/en-us/library/windows/desktop/ms724373(v=vs.85).aspx> 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 GetWindowsDirectory<https://msdn.microsoft.com/en-us/library/windows/desktop/ms724454(v=vs.85).aspx> 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-dlls-anyway/> 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 <[hidden email]> on behalf of Olaf van der Spek <[hidden email]>
Sent: Tuesday, October 11, 2016 12:24 PM
To: [hidden email]
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)
<[hidden email]> 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>, <string_view>) to 140; 150 is not yet ready to ship.

<string_view>, at last :p


On Mon, Oct 10, 2016 at 6:41 PM, Billy O'Neal (VC LIBS)
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Olaf van der Spek-3
In reply to this post by Billy O'Neal (VC LIBS)
On Tue, Oct 11, 2016 at 9:36 PM, Billy O'Neal (VC LIBS)
<[hidden email]> 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: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Beman Dawes
In reply to this post by Boris Rasin
On Sat, Oct 8, 2016 at 4:31 AM, Boris Rasin <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Billy O'Neal (VC LIBS)
In reply to this post by Olaf van der Spek-3
>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 <[hidden email]> on behalf of Olaf van der Spek <[hidden email]>
Sent: Wednesday, October 12, 2016 12:09:01 AM
To: [hidden email]
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)
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Gavin Lambert
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: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Billy O'Neal (VC LIBS)
>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 <[hidden email]> on behalf of Gavin Lambert <[hidden email]>
Sent: Wednesday, October 12, 2016 3:19:14 PM
To: [hidden email]
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

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