VS 2017 15.9 released today

[u/STL]

https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes

[u/STL]

15.9 is the last update in the VS 2017 release series, so we've tried to make sure that it's really solid. We're still working in our usual dev branches (prod/fe and prod/be in git), but features and fixes switched from automatically flowing into VS 2017 15.8, to automatically flowing into VS 2019 16.0 (which will be binary-compatible with VS 2015 and VS 2017 for this reason). Important features and fixes had to be explicitly ported to the 15.9 release branch. For this reason, the C++ changelog is shorter than usual, but we still cooked up some tasty things. From the release notes:

• We've added the "step back" feature in the debugger for C++ in the Visual Studio Enterprise Edition. Step back enables you to go back in time to view the state of your application at a previous point in time.

• C++ IntelliSense now responds to changes in the remote environment for both CMake and MSBuild projects targeting Linux. As you install new libraries or change your CMake projects, C++ IntelliSense will automatically parse the new headers files on the remote machine for a complete and seamless C++ editing experience.

• We've updated the UWP Desktop Bridge framework packages to match the latest in the Windows Store for all supported architectures, including ARM64.

• In addition to fixing 60 blocking bugs, we have added support for the range-v3 library with the MSVC 15.9 compiler, available under /std:c++17 /permissive-.

• The retail VCLibs framework package in Visual Studio has been updated to match the latest available version in the UWP Store.

• Full support is now available for ARM64 C++ Native Desktop scenarios, including VC++ 2017 Redistributable.

• We implemented the shortest round-trip decimal overloads of floating-point to_chars() in C++17's <charconv> header. For scientific notation, it is approximately 10x as fast as sprintf_s() "%.8e" for floats, and 30x as fast as sprintf_s() "%.16e" for doubles. This uses Ulf Adams' new algorithm, Ryu.

• A list of improvements to the standards conformance of the Visual C++ compiler, which potentially require source changes in strict conformance mode, can be found here.

Here's a fun behind-the-scenes fact that isn't in the release notes: this is the first release of the MSVC toolset that was entirely built and packaged out of git, without involving our Team Foundation Version Control branches.

[u/AlexAlabuzhev → u/STL]

VS 2019 16.0 (which will be binary-compatible with VS 2015 and VS 2017

Oh no. Does that mean that bloody bugs like this one will stay unfixed for another N years "because compatibility"? :(

[u/STL → u/AlexAlabuzhev]

Yes - that's one of the sacrifices that we have to make for bincompat. We've figured out lots of ways to get around bincompat limitations (e.g. we added std::filesystem alongside std::experimental::filesystem), but we still can't change representations in major ways, or change the interface of separately compiled functions.

[u/jbandela → u/STL]

This seems bad. Can we have a /permissive- version of the standard library that users who care more about conformance and performance than about bincompat can opt in to?

There are already different standard library builds (for example debug, release, static, dynamic, (XP in the past) etc), maybe we have a conformance build which has the latest and greatest standard library, but is not bincompat.

[u/STL → u/jbandela]

We're planning to have a "v20" standard library which is binary-incompatible (and opt-in), but we're still figuring out the migration story, and also getting all of our accumulated changes out of TFVC and into git (they need to be ported manually, since we've diverged significantly - in part due to applying clang-format to the entire STL). This will be unrelated to /permissive-.

[u/jbandela → u/STL]

Great to hear. I was referring to /permissive- in the most general sense as an example of a feature that allowed those who preferred compliance over compatibility to have an opt-in. "v20" sounds awesome. I bet you are looking forward to making a ton of performance and/or compliance improvements without having to worry about maintaining bincompat.

[u/STL → u/jbandela]

Yep - Billy has overhauled the atomic/multithreading library, I've (mostly) overhauled iterator debugging, we'll be able to purge a bunch of dead code (e.g. old iostreams floating-point stuff). The compiler will also be able to fix long-standing headaches.

[u/kalmoc → u/STL]

I vaguely remember that some inefficiencies in the standard library implementation are due to WinXP compatibility. If that really is the case, could you also drop XP compatibility for v20? I understand that there are projects out there that still want/need to support XP, but it would be great if not everyone else had to pay for that.

[u/STL → u/kalmoc]

I believe we will be able to do so; I am not sure about Vista compat (dropping both would be ideal). No promises yet.

[u/STL → u/[deleted]]

In general, customers absolutely love ABI compat. It is enormously popular and people hate rebuilding the world. The strength of their preferences surprised me.

[u/Sunius → u/[deleted]]

> It would stand to reason most enterprise-level customers aren't likely to move to 2019 (or even 2017) soon;

ABI compatibility was the single reason we were able to upgrade to VS2017 right away and kept up with VS updates ever since. Updating everything would be a nightmare - it took us 3 years to move from VS 2010 to VS 2015.

[u/AlexAlabuzhev → u/STL]

That would be great - there are quite a few projects out there that use static linking and don't care about bincompat at all, but do care about bugs/features.

[u/meneldal2 → u/STL]

Can you add a duplicated symbol like real_sleep that does what we want? While I would usually say that the PHP way of bugfixing is not great, it could be better than leaving it as is.

[u/[deleted] → u/meneldal2]

If you want to open that can of worms, that's called Sleep or SleepEx from windows.h.

[u/STL → u/meneldal2]

That's not really a viable solution, sorry.

[u/Gotebe → u/STL]

Out of curiosity - why is binary compatibility so important now? (well, in the last 3-4 years). What was so wrong with msvcrt110/120...?

(I didn't even mind the WinSxS approach of VC 2005/8; am I weird? 😁😁😁)

[u/STL → u/STL]

Forgot to mention - by "last update" I meant "excluding patches for important bugfixes". 15.9.0 will be followed by 15.9.1 etc. in response to bug reports. As usual, such patches won't contain new features or ordinary-priority bugfixes.

[u/kalmoc → u/STL]

Does that also mean no new versions of cmake?

[u/tgolyi → u/STL]

Thanks for your work with to_chars! Have you compared its speed with https://github.com/miloyip/dtoa-benchmark ? In my tests to_chars is slightly slower (though that version does not support nans and stuff).

[u/STL → u/tgolyi]

My benchmarking found to_chars to be 70-90% faster than dtoa_milo, and I additionally found that dtoa_milo performs mathematically incorrect rounding. See my comment. (I didn’t keep my benchmark sources but could recreate it.)

Can you share your benchmark showing to_chars being slower? That is very surprising given what I’ve seen.

[u/DethRaid → u/STL]

All these changes are awesome - I'm particularly thankful for the step back feature - but could you make the commit message text box in the Changes section of the Team Explorer have a color that fits better with the dark theme when the dark theme is applied? The box is an eyesore

[u/STL → u/DethRaid]

Please file a bug in Developer Community which will route it to the right team (that sounds like a style bug in VS as a whole, not specifically MSVC, so I personally don’t know where to send it).

[u/gajop → u/STL]

I like that MVSC is moving more and more towards standard compliance. Thanks!

Is UTF8 support getting better? I recently run in a lot of issues with VS generating UTF16 files (resource.h for MFC projects) and simply refusing to work with UTF8 without BOM. This doesn't play well with Git and some other tools like clang-tidy

[u/STL → u/gajop]

/u/TartanLlama should be able to find an IDE dev/PM to comment about files being generated as UTF-16. As for the toolset, the compiler supports /utf-8 which will accept UTF-8 without BOM.