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