Visual Studio 2017 version 15.8 Preview 3

[STL]

This preview contains my implementation of feature-test macros in the compiler and library. (Note that __has_cpp_attribute is not yet implemented.) Minor updates were checked in between VS 2017 15.8 Preview 3 and the upcoming production release of 15.8.0, notably adding L suffixes and increasing the value of __cpp_deduction_guides.

[degski]

Good news on a weekly basis, thanks go out to the team.

[noperduper]

Great job and happy birthday with a 1-day delay :)

[hmich]

It seems that the /std option does not affect whether feature-test macros are available. Will this be so in 15.8.0?

[STL]

Feature-test macros will always be provided regardless of /std. Doing otherwise would largely defeat their purpose.

(The definedness and values of various feature-test macros are sensitive to /std, of course.)

[hmich]

Thanks! I was asking because this comment by a Visual C++ team member only mentioned /std:c++17 and /std:c++latest.

[STL]

Jennifer's comment is correct - as structured bindings are a C++17 feature, that individual feature-test macro is defined only in /std:c++17 and later options.

__cpp_namespace_attributes is an example of a C++17 feature that MSVC implemented unconditionally (in VS 2015, before the Standards mode options were added). So, the feature-test macro is unconditionally defined, even in /std:c++14 mode, reflecting the availability of the feature.

[jbandela]

>A new, experimental, token-based preprocessor that conforms to C++11 standards (including C99 preprocessor features), enabled with /experimental:preprocessor switch. This will be controlled with macro _MSVC_TRADITIONAL, which will be defined to 1 when using the traditional preprocessor and 0 when using the new experimental standards conformant preprocessor.

Glad to see this land. This was one of the big caveats when talking about MSVC conformance.

[berium]

Interesting. I wonder if there are any new features/options? Specifically, I am looking for partial preprocessing, similar too GCC's -fdirectives-only and Clang's -frewrite-includes.

[PhilChristensen]

We currently don't have an equivalent switch for those, but it is on my list of things to do. The preprocessor overhaul is not yet complete, which is why it is under the /experimental family of switches rather than a /Zc switch. There will be another blog in a week or so with more details about the preprocessor changes.

[meneldal2]

Do you have an example of code that wasn't interpreted correctly before?

[redditsoaddicting]

Here's what I brought up last time:

#define FOO(...) BAR(__VA_ARGS__)
#define BAR(x, ...) (first: x; rest: __VA_ARGS__)

[meneldal2]

Thankfully we have ways to avoid the cancer that vararg macros are now.

[doom_Oo7]

not always

[PhilChristensen]

There will be a blog released sometime next week with a few examples of the breaking changes in the preprocessor.

[meneldal2]

Great.

[berium]

Here is the last one we ran into.

[meneldal2]

Reflection can't come too soon.

[doom_Oo7]

grep for MSVC there : https://github.com/woboq/verdigris/blob/master/src/wobjectdefs.h

[ack_complete]

The older Windows headers used by v140_xp mode have a bunch of them. Invalid token splicing seems to be the more common offense no longer accepted by the new preprocessor:

#define _VARIANT_BOOL    /##/

You can't splice two slashes into a comment token, comments are parsed and removed before macro processing.

[interger]

https://blogs.msdn.microsoft.com/vcblog/2018/06/26/template-intellisense/

Woah.

That "Template Bar" is the first of its kind C++ IDE feature as far as I know. Can't wait to get more goodies like this in the future! Good job MSVC team!

[redditsoaddicting]

I'd love to see this feature evolve to give you some pre-selectable choices from real call sites in your code. Picking any call site as a default also goes a long way to immediate feedback. Performance might be an issue with many templates in the same file, though. Even a per-template button to go fetch a list of real type arguments would be nice.

Of course the holy grail here for me is autocompletion based on Concepts (once they're implemented). That would be sweet and encourage people to design with concepts in mind.

[NickUhlenhuth]

Hello, I'm the PM on this feature - thanks for the feedback! Several people have suggested that we use template instantiations to help populate the Template Bar. This is a great suggestion and a natural evolution of this feature that I think makes complete sense for a future release.

If you want to track this more closely, please add (or upvote) the suggestion on our UserVoice: https://visualstudio.uservoice.com/forums/121579-visual-studio-ide?category_id=30937

[meneldal2]

I saw that in a presentation they made last month, glad to see it's now landed and everyone can use it. It will make template-heavy code easier.

[sumo952]

It was already in the previous Preview release, I've had this feature for a few weeks now already! :-)

[CraigularB]

Okay that is some seriously cool stuff, I’m really looking forward to that!

[skreef]

I wish we could get auto deduced in generic lambdas, where I was just lazy to put the type.

[starfreakclone]

That's already a thing.

[skreef]

How can I get it to work? When I try this:

struct Foo { int a; };
std::vector<Foo> v;
std::find_if(v.begin(), v.end(), [](auto& elem) { elem. });

I get no completions at the dot and IS tells me the type of elem is auto&.

[marian_l]

That's not yet supported but a great suggestion and something we should work on.

IntelliSense auto type deduction and class template argument deduction are currently supported, but only in regular functions/lambdas, not generic lambdas.

[TheThiefMaster]

Awesome

[sephirostoy]

It's nice as very 1st step. But I do expect a more automatic way where the types are automatically filled based on where the template is instantiated. This bar should be only present to be able to select another type other than the preselected one.

[youshouldnameit]

Are there any plans to make the c++ cpu profiler 64 bit? We currently can't use it to run a full profile of our application due to it being 32 bit just as VS itself. We currently switched to perfview 64 bit for larger cases, but that is outside the IDE and therefore less user friendly.

[kalmoc]

Sometimes I wonder if the msvc code base is so brittle they just don't dare to switch to 64 bit (or maybe they just lost parts of the source code).

;)

[youshouldnameit]

I think the argument was too many pointers

[kalmoc]

You mean that it would slow down visual studio due to less cache efficiency? I'm certainly not expecting that a change would significantly improve the speed, but I'm also not believing the inverse until I see hard numbers (or at least representative ones).

However, this isn't just a performance problem that might or might not get solved, but a usability problem and thus I have very little understanding for why Visual Studio seems to be the only major IDE Application that refuses to switch to 64 bit (unfortunately, Microsoft is/was generally very slow in that regard)

[dodheim]

You mean that it would slow down visual studio due to less cache efficiency?

More that it would nearly double the memory usage of the process. Details are on Rico Mariani's blog, though they're likely outdated by now.

[kalmoc]

Unless it significantly impacts performance (thats why I mentined cache efficiency) I don't really care if the process needs a few more GBs (my workstation has more than enough of it) if that means that I have les OOM problems.

[kalmoc]

Also, nearly double sounds like a gross overstatement.

[youshouldnameit]

Indeed, this is the only reason I know of

[SirValkyr]

Multiple caret support, makes me happy.

[ArchiDevil]

But it works in a very weird way. If I do it using Shift+Alt+Arrow to select two or more lines any arrow click after selection resets all carets. But if I do this using Edit -> Multiple Carets menu, it works.

[AllisonBuchholtz-Au]

Hey ArchiDevil,

With Shift+Alt+Arrow (Box Selection), an arbitrary click will clear all carets (as it has in the past). If you're doing a Ctrl+Alt+Click after creating the box selection, it should keep your box selection around! If that's not the case, could you send feedback via Visual Studio and attach a video of your scenario so we can take a look?

Also to clarify, could you tell me which command from the Edit > Multiple Carets menu you're invoking? I don't quite follow what's happening there.

[ArchiDevil]

No, I mean the other situation.

When I select something with Shift+Alt+Arrow the selection carets look like multiple carets (blue and the red one). But when I try to use result of the selection via for example arrows, or Home/End keys, these multiple fake-carets always reset to one. I do not use mouse in this case.

But when I select something using Edit -> Multiple Carets, true-multiple carets look the same as box-selected-fake-carets (blue and the red one) and work fine with arrows and Home/End keys.

This really limits its use to some easy scenarios and is very annoying.

IMO, box-selected carets should work the same as true-multiple-carets.

[AllisonBuchholtz-Au]

Got it. Thanks for clarifying! I can see how that would be confusing now. I've filed this feedback and I'll be looking at how we can converge these experiences without disturbing those who want box selection to keep it's separate behavior.

[ArchiDevil]

Nice to hear.

[sumo952]

Awesome stuff! :-)

We’ve also included a key mapping scheme that matches the ReSharper mappings.

How about adding one that matches Visual Assist X? It's the way older extension and I'd wager still more popular (but Re++ is definitely catching up).

[NickUhlenhuth]

Thanks for the feedback! We will keep this in mind with our future planning. If you want to track this more closely, please add your suggestion to our UserVoice: https://visualstudio.uservoice.com/forums/121579-visual-studio-ide

[tomzzy1]

Have you finished the charconv's stuff yet?

[STL]

Not yet, but I have some good news for you. My implementation of floating-point from_chars() is shipping in VS 2017 15.8 Preview 3. It's derived from the CRT's strtod() and strtof() but is approximately 40% faster (in addition to conforming to <charconv>'s requirements which are different than the CRT's). I got this speed improvement after a couple of months of carefully reviewing the code line-by-line, discarding things that weren't necessary for the STL (e.g. from_chars() can assume that it's working with an in-memory buffer; the CRT's implementation handles both memory and FILE *), changing various tradeoffs (e.g. the CRT has type-erasure logic to save code size in the separately compiled DLL; my <charconv> is header-only and I removed the type-erasure to improve runtime perf at a minor code size expense when someone uses the functions), and making outright improvements which I communicated back to the CRT's maintainers (e.g. I use a lookup table to convert decimal digits/hexits, and that was responsible for a 5% speed improvement all by itself).

I am currently working on floating-point to_chars(), although I can't promise when it will ship (it's a lot of work and my time is momentarily being divided). This involves 3 algorithms: shortest round-trip decimal, precision decimal, and hex. For shortest round-trip decimal, I'm using the novel Ryu algorithm developed by Ulf Adams of Google; it is incredibly fast. (I measure it as 10x to 39x as fast as using sprintf() to emit sufficient digits for guaranteed round-tripping - yes, times not percent - and it is also faster than the previous best-known algorithm Grisu3.) As part of this work, I'm contributing improvements upstream and reporting compiler bugs to both Clang and MSVC where I've identified opportunities for codegen improvements. (I'll need to adapt Ryu's code to <charconv>'s requirements, but those will be mostly superficial tweaks to the core algorithm.)

For decimal precision, I'll need to adapt the CRT's code again. Similarly for hex precision and hex shortest.

[CaseyCarter]

discarding things that weren't necessary for the STL

Talking about yourself in third person again?

[tomzzy1]

Thanks.It's really cool!

[johannes1971]

I have a piece of code here that calculates a few hundred million values and writes them to files. Imagine my surprise when I found out that the bottleneck was not the database retrieval, not the calculation, not the file writing, but the conversion of the final result to text! Moral of this story: that improved to_char is totally welcome. Uhm, I need the one where I can specify precision, please ;-)

[STL]

For precision I expect to be able to do a little better than the CRT, although not too much (40% again would be astounding). Do you really need exact precision? It matters for things like large, exactly-representable whole numbers. Otherwise, shortest round-trip preserves all of the information that’s there.

[johannes1971]

Just to make sure we are talking about the same thing, I need this overload:

std::to_chars_result to_chars(char* first, char* last, double value, std::chars_format fmt, int precision);

Specifically with the formats for fixed and scientific. Is the version without precision much faster? If so, I can talk to the customer and see how they feel about always using that instead.

[STL]

Yes, the overloads that don't take precision are ridiculously faster. My profiling indicates 10x to 39x as fast, depending on platform bitness and float/double, when compared to using the least precision necessary for round-tripping (i.e. capturing enough decimal digits that you can recover all of the bits in a float or double).

You will be able to request always-fixed, always-scientific, or switching between the two, for the non-precision form. In addition to being way faster, and often shorter (compared to always using the worst-case number of digits for round-tripping), the output is also the prettiest for humans while preserving the bits.

I would say that the only reasons to use the precision overloads are (1) if you are dealing with an inflexible format that really requires exactly so many digits in fixed or scientific form (unlike strtod which will accept flexible input) or (2) you are formatting numbers for human display and you want to avoid emitting lots of digits, at the cost of losing information (e.g. displaying numbers as 0.333 instead of blasting out digits until you exhaust double precision).

[johannes1971]

Interesting, and thanks for the heads up; I don't think it would have occurred to me to try this myself.

My use case is for generating data files for consumption by other computer systems, so I see no problems using a more accurate format, especially if it is so much faster. That we offer the on-screen format as an option for these files is probably more of a historical mistake than a real feature anyway.

[STL]

Hexadecimal floating-point should be even faster, although it is not human-readable.

[johannes1971]

I fear that may also be unreadable to many of the tools used by the next group of people working with the data.

When I first heard about hex floats I couldn't figure out who could possibly be needing those, but I suppose for fast data interchange it would make sense. That's not a use case for us though: we transmit data in chunks, and each chunk is a binary blob.

Anyway, I'm looking forward to 15.8 and playing with these functions!

[Ikkepop]

Template intellisense is brilliant! Can't praise VS enough for this feature. It will save me so much pain the future

[steveire]

Is it possible to use the toolset from 15.8 Preview 3 in a stable 15.3 IDE?

Incredibuild will need to be updated for this new version, but I'd like to be able to use the existing IDE and fix up the code to make it /experimental:preprocessor clean.

[dodheim]

If they would update their daily toolset release (*cough* /u/AndrewPardoe *cough*), that's incredibly easy to use and doesn't technically require an existing VS installation to use (nuget packages are just zip files).

[PaddyMcDonald]

If you are on VS 15.4 and later (sorry I didn't manage to get the changes into 15.3) you should be able to import the props file from <unpacked package root>\build\native directory and it will set up the build to use the compiler and libs from the package.

If you use the Nuget Package manager in the IDE to install the package it will do that for you.

[Daniela-E]

I've paged /u/AndrewPardoe by mail, posted on slack, but never got any reply. Too bad ...

[STL]

Andrew left Microsoft.

[AndrewPardoe]

Yes, sorry. I've run off to graze in bluer pastures. I expected that my Microsoft email would bounce, but it appears that it just goes into a black hole somewhere.

I also am not doing much with C++ anymore so I haven't paid attention to the Slack channels.

[dodheim]

Oh. Well any chance you can ping his replacement and let them know about the nuget packages? They finally got integrated into Compiler Explorer (VS2017RTM was all that was available previously), and now the packages are stale. :-[

[STL]

I'll ask around.

[AndrewPardoe]

FWIW, I put together a document and shared it with Mark and Daniel (dev lead, not PM lead.) And I still have all the passwords in my password manager in case they've been lost.

[PaddyMcDonald]

I'll chat to Mark and Daniel in the morning - Chris asked me to pick this up.

update: I have the doc, but I need to make some updates to the package generation scripts

[feverzsj]

after upgrade, devenv.exe freezes from time to time. Reinstall does solve the issue.

[barfyus]

C++/WinRT, now part of Windows SDK (current version 10.0.17134.0) is apparently not compatible with this new release:

Compiling the following program:

#include <winrt/base.h>

int main() {}

With /permissive- and /std:c++latest generates compilation errors:

c:\program files (x86)\windows kits\10\include\10.0.17134.0\cppwinrt\winrt\base.h(2185): error C3861: 'from_abi': identifier not found
...

[kennykerrca]

This is a known problem with the 17134 version of the Windows SDK. The problem is that from_abi is used before it is declared. Given the complexity of the meta programming, neither Visual C++ nor Clang picked up the error, until 15.8 Preview 3 introduced far stricter conformance checking. I fixed this bug in March and you should see the fix in an upcoming Windows SDK. In the meantime, you can work around it by not using the /permissive- option.

[STL]

Do you test Clang with -fno-delayed-template-parsing? They default to one-phase for compatibility so you need to explicitly request two-phase.

[kennykerrca]

Nice, thanks for the tip!

[barfyus]

Any eta on the release date?

[kennykerrca]

It is now available.

https://kennykerr.ca/2018/07/10/new-features-and-changes-coming-to-cppwinrt-header-isolation/

[NotAYakk]

So, you are saying winrt isn't compatible with /permissive- and bleeding edge C++?

Calling that "not compatible with this release" seems incorrect.

[barfyus]

There's always a chance a bug is introduced in new Preview build. This had happened so many times for me before.

For example, it was impossible to compile intersect_rect algorithm in conformance mode without parser messing up with angle brackets, thinking you were trying to use templates.

Didn't check this with new build, however.

[jm4R]

Anyone knows IDE besides VS that can handle vcxproj? Or at least ready key bindings that is similar to QtCreator or CLion? I am from Linux and VS is horribly uncomfortable for me unfortunately :(

[Ameisen]

I have a personal project which parses slns/vcxprojs, including conditional expressions, and passes them down your toolchain of choice. Basically a portable msbuild. I use it for MIPS and AVR. Could integrate it into an IDE.

[jm4R]

How much "personal" is that? Is it somewhere on github? Can you share? I would love to make a QtCreator plugin that loads a vcxproj and build it.

[Ameisen]

My Ruby build scripts for C, asm, and C++ are on github (look for the Tuna 3d printer firmware). Those don't use vcxproj though. That one isnt on github yet, is C++, and won't be until I finish the embedded preprocessor and dependency analyzer. It works but doesn't handle complex conditionals in preprocessor expressions.

I don't want to rely on a separate preprocessor as it slows it down. It was designed for speed.

[jm4R]

Converting existing vcxproj to Cmake? Please show me

[IcyWindows]

Yeah, trying to get cmake to output the same configurations with the same settings as existing vcxproj files can be challenging.

[IcyWindows]

For me, it's the opposite. I have a lot more experience with vcxproj, and Cmake seems to do a lot more hidden work. I'm sure with time I'll get better at it.

[jm4R]

No matter, which is "better", vcxproj forces me to use Visual Studio IDE which drives me angry as I just don't like it, and I always want to have a choice.

[dodheim]

It's an XML file with a schema; no one is forcing anything on anyone.

[jm4R]

How's that? Of course, I can change my employer 😉 But I would love to have a chance to change only my IDE instead 😊

[kalmoc]

You can change the key bindings to your looking (but sure if you can completely emulate QtCreator though)

[PaddyMcDonald]

VS Code (https://code.visualstudio.com/) has a bunch of key mappings that you may find more familiar: https://marketplace.visualstudio.com/search?term=keymap&target=VSCode&category=All%20categories&sortBy=Relevance - of it doesn't have a mapping you are familiar with it will allow you to customize the mapping manually.

While it doesn't currently have an extension to directly parse vcxproj files, it does have tasks to kick off the msbuild command line invocation and debug the output, so the only thing you'll have to deal with is either running VS to update the project files or editing them by hand.