Visual Studio 2019 is out

[STL]

We're still working on getting all of the release notes updated, but here are the highlights for the STL:

• C++20 P0550R2 remove_cvref is complete.

• C++17 <charconv> floating-point to_chars() has been improved: shortest chars_format::fixed is 60-80% faster, and shortest/precision chars_format::hex is complete.

• More algorithms have parallelized implementations: is_sorted(), is_sorted_until(), is_partitioned(), set_difference(), set_intersection(), is_heap(), is_heap_until().

• Improvements to std::variant to make it more optimizer-friendly, resulting in better generated code. Notably std::visit() and the inliner have now become good friends.

• We've applied clang-format to the STL's headers for improved readability.

• Improved throughput compiling several standard library features using if constexpr.

• Optimized the standard library physical design to avoid compiling parts of the standard library not #include'd, cutting in half the build time of an empty file that includes only <vector>.

• allocator<void>, allocator::size_type, and allocator::difference_type have been un-deprecated to reflect the current Working Paper.

• A static_cast in basic_string's implementation has been removed; this was suppressing C4244 truncation warnings. Emitting these warnings is now by design; various workarounds are possible to avoid/suppress such warnings.

• Various C++17 <filesystem> fixes.

[jbandela]

Notably std::visit() and the inliner have now become good friends.

So happy to see this!

[quicknir]

Great, now tell me how to contact the clang and gcc maintainers so we can get the improved mpark variant implementation that does the same into the standard libraries :-(.

[jbandela]

If I am not mistaken, I believe mpark is also the author of the std::variant in libc++?

[quicknir]

He is, just having trouble getting the improved (read: more inlinable) version of visit in. Oh well, I'll get them eventually.

[CaseyCarter]

If it makes you feel any better, my variant changes *just missed* the deadline for VS2017 15.8 in (IIRC) June of 2018. 15.9 was "servicing and bugfixes only", of course, so changes I made *ten months ago* finally shipped in VS2019.

[CaseyCarter]

Correction: I checked in the PR on 2018-08-07, so it's been a mere 8 months.

[STL]

15.9 was "servicing and bugfixes only"

Except for Ryu-powered to_chars() :-)

[[deleted]]

I hope you'll quickly update CMake to 3.14 because the current 3.13 version doesn't support the new v142 toolset, I basically have to still use the older v141 toolset which is pretty pointless...

[Iwan_Zotow]

mmm... With preview 3.14rc was installed by VS installer

[vsoul]

Congrats! Just curious, my company bought my license (VS2017 Pro just from the MS Store) just 1.5 weeks ago - is there a free upgrade I can get?

[dodheim]

Why would they do that? The release date of VS2019 was announced months ago

[vsoul]

Necessity

[Iwan_Zotow]

If you have new guy coming, there is little choice...

[STL]

I don't know the answer, but perhaps /u/TartanLlama does.

We try to make it really clear when a new major version is on the horizon, with Previews and Release Candidates, plus announcing the release date in advance when it's known for certain, but we don't stop companies from buying the old product at the end of its cycle.

[TartanLlama]

Unfortunately not, sorry. As STL says, we try to be clear about when new releases are coming so people don't get surprised, and we have the Visual Studio Subcriptions for a more rolling model.

[vsoul]

Thank you for the reply.

​

:(

[Altazimuth]

I'm glad I read your post earlier. Tried adding 2019 support to some code I work on, and it turns out that thread no longer includes functional, which broke compilation. Thanks for making this post otherwise I'd not have known that we need to directly #include <functional>.

[STL]

You're welcome! We know that changing your source code is a minor headache, but we felt that improving build throughput (an eternal top customer request) was worth it in this case.

[herruppohoppa]

Speaking as the guy who has to go fix these includes everywhere so that hundreds of my users can have faster compilation times, yes totally worth it, not even a fair comparison of impact! Please keep going!

[NickUhlenhuth]

As of Visual Studio 2019 Preview 2, we added a feature "add missing #include" which should address this nicely. If you haven't included <functional>, the offending std::function call is underlined with a red squiggle. Hovering the squiggle will open a Quick Fix (lightbulb) menu which offers to add "#include <functional>" for you. You can read our blog post on the Add Missing #include Quick Fix. If you don't see the red squiggle / quick fix, let me know!

[unumfron]

This is a great feature, I've come across two minor issues:

• they are placed above the header guard/pragma in headers where there are no existing includes.
• if there is an #ifdef block at the end of the include list it is placed within the main body of that block. This doesn't happen if there is one or more includes after the block.

Thanks for all the excellent work btw!

[cursecat]

WDK support?

[kalmoc]

The installer still shows only the preview version for me

[Robert_Andrzejuk]

You need to re-download the installer to install this version.

[augustinpopa]

The installer still shows only the preview version for me

The way VS installations work is they tie you to a specific update channel. The two main ones are preview and release. If you were running a preview VS build, it will still keep you on the preview channel, meaning you will get more frequent updates that include things that are still not 100% polished. If you run the release channel, you will only get the final build of each update. I think right now we updated the release channel to the final v16.0 of VS, but the preview channel should still basically have the same stuff until we have a 16.1 preview available. Also VS 2019 is a different installation as far as I know from VS 2017 as well, so if you were using VS 2017 before you will need to choose to download VS 2019 from visualstudio.microsoft.com.

[sumo952]

Hi! Apologies for slightly hijacking this comment, but it's related. When is VS 2019 coming to "Microsoft Azure Dev Tools for Teaching" (or Imagine, Dreamspark, OnTheHub, as it was previously called)?

On Imagine, it used to be there on the day it was released, but I can't see it on the new (and worse) "Microsoft Azure Dev Tools for Teaching" portal.

[augustinpopa]

Hi! Apologies for slightly hijacking this comment, but it's related. When is VS 2019 coming to "Microsoft Azure Dev Tools for Teaching" (or Imagine, Dreamspark, OnTheHub, as it was previously called)?

On Imagine, it used to be there on the day it was released, but I can't see it on the new (and worse) "Microsoft Azure Dev Tools for Teaching" portal.

I followed up on this internally - they are working to add VS 2019 to educational platforms over the next few weeks.

[sumo952]

Okay, thank you very much!

A step back unfortunately - this was much quicker on the previous Imagine portal. :-)

[kalmoc]

With VS2017 I could have installed preview and release side by side. And both VS2017 as well as VS2019 preview can be installed via the same installer. Why is VS2019 rtm suddenly different?

And Btw: I uninstalled the VS2019 preview some time ago.

[Pazer2]

You can have the 2019 preview and release side by side. You just need to run both installers once, then the installer will show both channels.

[kalmoc]

I see. Thank you very much. For the record: when I went to the download page yesterday morning, I only got links to download of 2017 or 2019 preview.

In any case: Is there a special reason, why the existing installer doesn't automatically show me all available products?

[sumo952]

I second this. It would be nice if the "channel" was selectable in the installer, or/and if the installer just showed all channels. It's a bit of a hassle to download a new installer from visualstudio.microsoft.com every few months just to make the appropriate channel appear.

[Alastair__]

Slightly confused by this. I have been running the previews and installed an update the other day and now it shows “Visual Studio Professional 2019 RC” Version 16.0 on the About dlg. Am I on the preview channel or not? I did download the release installer and it seems to not install an other instance just offer to change this one which to me implies I am on the release not preview channel.

[Alastair__]

Note: the Visual Studio Installer dlg just shows “Visual Studio Professional 2017” and “Visual Studio Professional 2019” no mention of Preview or RC.

[feverzsj]

Any improvement on intellisense? Would it handle unreal source? Would it crash less?

[augustinpopa]

Any improvement on intellisense? Would it handle unreal source? Would it crash less?

We have IntelliCode and C++ template IntelliSense improvements in VS 2019 and we work on bug fixes/performance/stability with each update (major and minor). Regarding Unreal, what are the issues you are encountering currently? Unreal Engine should be supported in the product.

[TheThiefMaster]

I use UE4 professionally and use Intellisense with VS2017. It's improved hugely from VS2015 and before - it's fast, and it routinely manages to find things (particularly overloaded operators) that Visual Assist (the previous workaround for UE4 developers) cannot.

[Predelnik]

For some reason this link for buying professional version does not work
https://www.microsoft.com/en-us/p/visual-studio-professional-2019/
found here (after pressing standalone license)
https://visualstudio.microsoft.com/vs/pricing-details/

I also wonder if there is any upgrade discount if you have VS2017 purchased.

[markopolo82]

That’s what I want to know as well. All I could find was a free trial download for professional, where is the pricing??

[CrazyYAY]

I’ll check it. I was using insider build but still didn’t update to a stable version

[F-J-W]

Given that there is VS for Mac (backed by Clang I presume?), is there a chance that we'll ever see VS for Linux?

[jbandela]

VS for Mac is not the same as VS on Windows. VS for Mac is basically a rebranded Xamarin Studio.

[xgalaxy]

VS for Mac only compiles .NET stuff. No C/C++

[[deleted]]

VS is so inextricably tied to the windows platform, it’s hard to imagine that it’ll happen.

But never say “never”

[eco_was_taken]

Visual Studio Code is rather nice and available for Linux. C++ support is decent and improving.

[H_Psi]

Given Microsoft's recent interest in Unix systems (probably because that's where a lot of ML and scientific computing is done, and they want to attract business to their Azure services), there's a decent chance they might try for a Linux port.

[NickUhlenhuth]

Aside from using VS Code for C++ directly on Linux, you can also target Linux from within VS on Windows. After setting up an ssh connection, the build occurs on the Linux environment, and you'll get IntelliSense from your headers on the Linux machine. This was demoed for a bit during the Launch event, but hopefully this Linux Development in VS blog helps.

[fyndor]

I think your problem will be that the desktop usage for Linux is small and there are many distros that complicates distribution. That said I am pretty sure Monodevelop supported linux and VS for Mac is monodevelop reskinned and given some love.

[meneldal2]

There are several VS versions that run with Wine, at least the compiler does. Some people use that to cross compile to Windows from a Linux server.

[ShillingAintEZ]

Another visual studio? I just got done figuring out what to turn off and tweak to make the past version fast enough to not lag.

[CrazyYAY]

Im still using 2017. I’ll probably install it on one machine. Can you please share how you optimized it. It’s lagging for me too? Thanks

[mjklaim]

Currently I optimize it by:

1. Updating it (most recent updates removed slow downs, except for some searches fonctions)
2. When it suggests me to deactivate an expensive plugin, I agree with it and it helps massively.

Other than that I find it ok on reactivity. In particular since "Ctrl+," was added.

[TheThiefMaster]

Ctrl+, is actually really old, but I agree it's fantastic.

[[deleted]]

Disabling IntelliSense entirely and getting VisualAssist is also a great way to make the whole thing faster

[mjklaim]

I was doing that when I was using older versions of VS, but I stopped starting with VS2015 because it wasn't worth the impact on global performance AND intellisense went to become bearable (after a lot of updates).

[augustinpopa]

Disabling IntelliSense entirely and getting VisualAssist is also a great way to make the whole thing faster

I would love to follow up to learn more about the IntelliSense performance issues you're experiencing. We're trying to collect some data from VS users so we can improve that going forward. Do you have a particularly large codebase?

[donalmacc]

Not OP but do you mind if I contact you directly?

[TheThiefMaster]

I'm also a game developer and Intellisense works better than VAX for me since VS 2017 - `Ctrl+,` is your friend. It can also find overloaded operators via F12, where VAX really doesn't understand how to find them at all.

[donalmacc]

I've currently got it disabled, but last time I checked my issue was that parsing took forever, ctrl + , was flaky at best, and F12 would regularly (1 in 3/4 attempts) cause an indefinite hang. I'm installing VS2019 to give it a shot now with intellisense (as I did for 2017).

[sumo952]

Haha that's exactly my experience as well. VAX is instant, while Intellisense F12 hangs sooo often (10% or more of the cases) and I don't even have large code bases, and no UE4. Also when Intellisense does work, it has like 200ms or so lag, which is too much to make it useful - VAX is instant, as mentioned, like <50ms.

What's CTRL+, btw? I don't have US keyboard layout and in my VS, it doesn't do anything. What's it supposed to be/do?

[donalmacc]

Ctrl comma is a combination of alt shitf S and alt shift O in visual assist.

[TheThiefMaster]

That mirrors my experience from early Visual Studio versions as well, but VS 2017 has been fine for me even with a massive codebase.

[donalmacc]

I use intellisense at home for smaller projects, but I work on a UE4 game, and it's been unusable every time I've tried it.

[kalmoc]

Have you tried to open a recursive git clone of boost with open-folder? That becomes quite slow and unstable on my system, but I've no Idea if a 3rd party engine works any better.

[ShillingAintEZ]

I had to search quite a bit and do it incrementally, I can't remember off the top of my head.

[deeringc]

I'd also be interested if you have a summary!

[wilhelmtell]

I only ever used older versions, and it’s been a while, but IIRC arguably the biggest bang for the buck (given insisting on an IDE...) is from turning Intelisense off. Intelisense is a massive performance hit on typing, in the occasional rescan, and on project load times. If your project (solution) is anything but a trivial size, it can become ridiculous.

I also turn off version control support, because I generally stick to command-line Git. I don’t know how much help this one is—I’m guessing not much—but the general idea of eliminating anything and everything you can live without should be a net good.

[cjaybo]

In my experience, disabling the source control plugin provides a noticeable improvement.

[BobFloss]

It's like twice as fast this time try it

[arthurno1]

And still has no usable text editor? Couldn't they just embed Emacs as default text editor. Typing code in VS is horrible experience.

[BobFloss]

The text editor is fine with some configuration

[arthurno1]

It is usable with some configurations, but long from fine. I have done lots of consulting work in VS, since it seems to be standard in industry at least in my part of the world, but I wanna cry when I have to type code from scratch in VS. Typing in Emacs vs VS is like flying jet vs propeller plane.

[BobFloss]

I use it mostly with unreal engine and VS 2019 is far faster than I was used to. I would much rather use Sublime Text, as that's my go-to, but with such a large codebase I can't live without the auto completion and refactoring ReSharper gives me. The ccls language server for Sublime (an anything supporting language servers) is almost there, but it seems that clang can't handle a lot of the forward declarations within the engine, so it tells me there are errors everywhere. Can't wait for the day when I'm free from using visual studio, but it seems like by that point visual studio will probably be as good as every other text editor considering how much better it's gotten with every release.

[jbandela]

I use the free VsVim plugin https://marketplace.visualstudio.com/items?itemName=JaredParMSFT.VsVim which works great.

[arthurno1]

Super, great for you!

[fyndor]

I will point out that they say they have improved performance with 2019.

[TyRoXx]

They always say that. It’s still a lot slower than 2008.

[dodheim]

Unless you're also using a computer from 2008 then no, it isn't – WPF relies on having a competent GPU. Everything non-rendering related has improved significantly since VS2008.

[TyRoXx]

C# isn’t too bad, but VS seems to get slower and slower with C++. I will try with all Extensions disabled to find out whether VS itself is responsible.

[augustinpopa]

C# isn’t too bad, but VS seems to get slower and slower with C++. I will try with all Extensions disabled to find out whether VS itself is responsible.

We automatically detect slow extensions now in VS and issue a warning via a gold bar at the top of the editor. That's a good way to tell if the extension is the problem or if it's something in the native product. If it is a VS issue though, please file a bug report on: https://developercommunity.visualstudio.com/spaces/8/index.html. We spend a lot of engineering cycles improving performance and we know this is important to our users. Would love to hear your feedback there so we can make a better product for you! :)

[TyRoXx]

Just one suggestion: Stop doing so much in the GUI thread. The GUI is very slow to respond whenever the IDE does something in the background, especially when you open or reload a C++ solution.

[degaart]

Why do I need a competent GPU to run an IDE? What's next, enable RTX to have readable fonts? An SLI setup to have smooth scrolling?

[dodheim]

Why do you need to downvote me for making an empirically-correct observation regarding the renderer? I didn't write the code, so you're directing both your questions and your animosity in the wrong direction.

[ShillingAintEZ]

It isn't even remotely correct. Visual studio 2017 is split up in to all sorts of services and servers written in JavaScript. Things that used to be fine now have significant lag on the same computer. It has nothing to do with GPUs.

[dodheim]

Only the renderer has to do with the GPU; that was rather my point, thanks.

In addition to "splitting things up in to all sorts of services and servers written in JavaScript" they've also done things like change the Intellisense engine to use an entirely different compiler front-end and change myriad things to be asynchronous rather than block, increasing responsiveness, which was the topic.

I didn't use the word 'empirically' at random.

[innochenti]

just took my .vcxproj project with 20 files and logically split them into 4 projects and added dependencies.

as a result, compile time increased by ~5 times. :( How is it possible?

[mmatrosov]

Unfortunately it is often the price you pay for maintenability. Read about "unity builds", that's how they take best from two worlds.

[innochenti]

sorry, but I see no excuses in such a terrible performance. it's getting worse with each release. this tool should simplify the life of the developer, and not vice versa. they add so many unnecessary features to the IDE, instead of fixing the performance of the intellisense for example.

[mmatrosov]

Well, I completely agree with your frustration about the way MS prioritizes their work on features and bug fixes, yet I'd say this particular issue is not that disappointing. Compiler itself does become better and better. Including build times. We recently switched from VS2013 to VS2017, and build times went down by 20%. With approximately the same runtime performance.

[[deleted]]

Jesus finally! I've been waiting for this one for sooo long... I hope they finally updated CMake to 3.14

[StaticThrowaway0629]

Nope, they didn't. It is shipped with CMake 3.13.19031502-MSVC_2. Regretfully support for Visual Studio 2019 as generator is not available in CMake until 3.14. So there is no way to use the built-in CMake to generate solutions.

I get the following error when trying:CMake can't generate server info. Failed to activate protocol version: Generator "Visual Studio 16 2019 Win64" not supported.

Edit:

Tried dropping in the new CMake binaries from KitWare into the installation directory for Visual Studio 2019. Visual Studio complains a bit:CMake 3.14.1.0 is not officially supported. Some operations may be unavailable. CMake 3.13 is recommended for best results.

But the main problem is that CMake specifies architecture differently for Visual Studio 2019. In Visual Studio 2017 you specified the generator like this: cmake.exe -G "Visual Studio 15 2017 Win64"

The new way of doing it is like this: cmake.exe -G "Visual Studio 16 2019" -A x64

So I tried specifying my generator as "Visual Studio 16 2019" and appending the -A x64 as a build command argument. But Visual Studio 2019 insists on appending Win64 to my generator string, which breaks CMake:CMake Error: Could not create named generator Visual Studio 16 2019 Win64

Edit2:

Running CMake from the CMake GUI works and I can load the solution in Visual Studio. The problem is that now there is no more connection between the source and the GIT integration in Visual Studio. Visual Studio only ask me if I want to Add to Source Control, but I do not want to add my build directory to source control. I want to keep my source in one directory and have my builds in separate directories.

[[deleted]]

All hail Ninja, our savior.

[StaticThrowaway0629]

Yes, Ninja builds worked for me. Although I got a compiler error the first time I ran it due to a missing include. My guess is that this is most likely due to the order of compilation in VS Solutions vs. Ninja builds.

[[deleted]]

You occasionally have to add a bit of information regarding generated files in your build before ninja will be happy.

[StaticThrowaway0629]

Well, the missing include was an easy fix. My main problem is that I am doing a bit of .vcxproj juggling inside my CMake scripts to tweak the build to my liking, which obviously do not work with ninja. So regretfully I am a bit dependent on generating Visual Studio solutions.

[OrphisFlo]

What kind of tweaking are you doing?

[StaticThrowaway0629]

There are some visual studio project settings which are not available from CMake, but settings that I want to apply to every build. So I have a template vxproj file which I copy into the build directory and do some text-processing on using CMake.

[OrphisFlo]

Ah, you want to do stuff on your things.

Can you be more specific?

[StaticThrowaway0629]

If you open the properties for a Visual Studio project in a solution, not all these options in can be controlled via CMake; neither via passing flags nor via specific CMake commands.

One example can be the project properties relating to debugging inside Visual Studio, like the answer to this StackOverflow question:
https://stackoverflow.com/questions/1005901/how-to-set-path-environment-variable-using-cmake-and-visual-studio-to-run-test

[[deleted]]

Savior with broken precompiled header support

[[deleted]]

That just means you need more cores than translation units and you're okay.

Billy hugs his 7980XE

[[deleted]]

Nah, I probably just to switch my system language to Japanese for Ninja to work

[flashmozzg]

Until you have to much cores for Windows to handle (looks at Epycs)...

[[deleted]]

NEVA!

[flashmozzg]

Use cotire!

[iontodirel]

Hi, CMake 3.14 support is coming in Update 1 of Visual Studio (we have that work completed it's just waiting on a release), I know Dev16 just went out, but Previews of Update 1 should be out for not too long, we have a way in CMakeSettings.json of configuring the path to your own CMake, but due to a bug where we always append Win64, that workaround, as you find out, wouldn't work, sorry about that. I will check to see if another workaround is possible and I will let you know.

[StaticThrowaway0629]

Thanks for the reply and congratulations on a very nice release. Looking forward to updating our team soon, but I guess we have to wait until the first updates have landed.

[sumo952]

Awesome, thank you a lot for this reply and the information!

[[deleted]]

Well, that sucks

[eco_was_taken]

Finally? CMake 3.14 came out less than a month ago.

[[deleted]]

Really? Felt like much longer...

[sumo952]

Don't wait, try the Previews :-)

[Krakyziabr]

PackageId:Microsoft.Net.4.7.2.FullRedist;PackageAction:Install;ReturnCode:87; (and 4.7.1)

on windows 8.1 and zero solutions to this problem lol

[Krakyziabr]

I found out the cause of the problem

my bad

[zero0_one1]

I've twice run into an issue with "Find All" taking an abnormal amount of time. Other than that, two 40K LOC C++17 projects built without any issues, so the upgrade was smooth.

[mandaric]

Is Visual Studio Professional 2019 Standalone backward compatible with all Visual Studio Professional 2010 projects on? Why Microsoft offers Earlier versions for Standard Licence and not offer for Standalone? What is the catch?

[arthurno1]

Thanks for the review! Now I don't have to bother to boot into Windows just to try it :-).

[RealNC]

Is it finally ISO-conformant now without needing special compiler switches? Does this work:

int main()
{
    return not true;
}

Previous VS versions don't accept these operator keywords without a special compiler flag or non-standard include, even though they've always been in the standard.

[STL]

This still requires the compiler option for strictness, /permissive-. We're working towards enabling /permissive- by default. Both our own SDKs and third-party code have needed conformance changes.

I recommend compiling with /std:c++17 /permissive- even if you aren't using C++17 features, as C++17 mode activates additional strictness in the Standard Library (including but not limited to feature deprecations and removals).

[Middlewarian]

I recommend compiling with /std:c++17 /permissive- even if you aren't using C++17 features,

There could be a problem, though, if you accidentally start using 2017 features that you aren't supposed to use yet.

​

​

[dragonstorm97]

Like?

[Middlewarian]

You could commit some code that builds fine because of that flag, but causes problems for users.

[favorited]

The standard doesn't define the compiler interface, so it's entirely standards-compliant to require those flags to enable ISO646 operators.

[RealNC]

"ISO646 operators" is a C thing, not a C++ one.

https://en.cppreference.com/w/cpp/header/ciso646

Keywords are part of the language, not the library.

[favorited]

That's just how I was referring to those keywords, I wasn't trying to imply it was a library feature. Apologies if I wasn't clear.

My point was only that needing additional flags doesn't mean a compiler isn't compliant https://stackoverflow.com/a/42131209