With each release, we implore (beg?) you to provide feedback through whatever channel works best for you. This time, we are trying an experiment. Please provide short, in-the-moment feedback through Send-a-Smile or Send-a-Frown and include the tag #cpp2015. We want to be overwhelmed by good (or not) feedback from you, our users and biggest fans/critics. Thank you!

For more information about features for C++ developers in Visual Studio 2015, check out these articles on VCBlog:

You may deploy the Universal CRT app-locally. We'll have more details about this later this week. In brief:

DLLs for app-local deployment are now included in the SDK under C:Program Files (x86)Windows Kits10Redist. We discovered very late that the DLLs actually packaged into the SDK are incorrect and do not work; there will be an SDK update soon with "fixed" DLLs. (In the meantime, you can get all of the DLLs by installing the redistributable on a Windows Vista machine and obtaining the working DLLs from the system directory.)

Note that on Windows 10, the real Universal CRT in the system directory will always be used, even if you have the Universal CRT DLLs included app-locally.

As an occasional bug reporter I would like to ask, is there any chance that Connect would be somehow modernized or maybe even replaced with something different entirely? With all due respect but in my point of view it does not have all the qualities required from modern convenient bug tracker.

Create something like what Xamarin is doing in order to help developers to code once and run EVERYWHERE (Wndows 10, windows 10 mobile, android and ios).

If Microsoft could not buy Xamarin, at least do what they are doing by your own. Make something that enable us to archive real NATIVE cross platform development. It could dramatically increase the numbers of developers using .net to create mobile applications as well as increasing the number of apps created to wp too, since app could be compiled to ios, android AND WINDOWS PHONE. Hibrid apps like apache Cordova has a lot of potential but right now it is limited to offer a bad user experience when compared to the native apps you could build native with native objective-c on iOS, java on Android or C# (on Xamarin.Forms o WP and Windows 8). Porting .net to others platforms is good, but go further MS, create something that help us to "code once and run everywhere. And by EVERYWHERE I mean, not just windows, I mean: Native apps on Android, iOS, Windows PC, Windows Mobile, Xbox, HoloLens and to on. Bring us a tool that enable us to make Visual Studio Universal Apps REALLY UNIVERSAL (running as well on android and iOS).

We want a Framework that enable us to build NATIVE.

By the way Xamarin Starter edition has a very limited package size so is almost impossible to create even small apps with an organised architecture (multi layers) and its licences fees is very expensive too.

Hey M$ look to the opportunity a tool like Xamarin could bring to the windows ecosystem. It could help you to resolve the app gap Windows Phone suffers so far. With a tool that can help developers to build native applications to windows as well as to android and iOS could bring the apple and android developers interest to use it and since it will be able to compile to windows phone then they will not have why to do not do so. It will also bring mobile developers form other platforms (android and iOS) to Visual Studio and .NET.

Congratulations! This is the first time after a lifetime that Microsoft compiler gets C99 compliant!

Thank you!

Please focus on C99 and C11 in future releases and:

"get fully compliant with the C-std once and for all" <- i wonder, does this not appeal your bosses, customers, audience and the whole world? From where I sit, this is a HUGE deal! Basically what it means is we need the remaining five C11 missing headers available in MSVCR. Please don't wait for C++21 to include C11 by reference, so you implement C11 std in 2030. :-)

Regarding this: "We discovered very late that the DLLs actually packaged into the SDK are incorrect and do not work; there will be an SDK update soon with "fixed" DLLs."

How / where will we be informed as soon as the appropriate SDK update is available? Will it be an update offered Inside VS.2105? Should we check somewhere else for this updated SDK?

Regarding this: "In the meantime, you can get all of the DLLs by installing the redistributable on a Windows Vista machine and obtaining the working DLLs from the system directory."

On the one Vista (x64) VM which I had around here, the vcredist_x64.exe taken from VS.2015 installation tree, miserably failed by its end (never ending indeed). After more than 30 minutes, had to kill it. Now always returns a fatal error on every new attempt. I clearly should re-install a new Vista from scratch, but to merely get the *right* universal CRT dlls, I'd prefer to download the updated SDK than loose time with Vista issues.

It works if I convert Spatial{*this} to Spatial(*this). My intention is to copy construct and instance and I think the Spatial{*this} syntax is actually less ambiguous here (it cannot be mistaken with a function call).

There isn't any document about C++ Attributes in MSDN? And the new warnings are not documented,too.(such as warning C5030). Also, msdn.microsoft.com/…/hh567368.aspx says VS2015 doesn't support Attributes.

@Yupei. Thanks for the feedback. I'll correct the feature list wrt Attributes; they are in fact supported in 2015. The MSDN documentation for attributes is on our backlog and should be appearing in a month or so. Content for errors and warnings will follow after that.

I'm unable to find any C++-related help content in VS 2015 Community Edition (C++ support installed). In fact, the help index whole 'Recommended Documentation' part is very sparsely populated. Could anyone comment?

@Klaus, your question picked up my curiosity could you give me an example of program compiled for example by clang with optimizations where adding/removing constexpr generates different asm code? I mean constexpr changes thing syntactically because you could put constant expressions in more places than normal ones but I'm curious could it really optimize things in that regard more than normal inlining/optimization? (And as far as I can understand it shouldn't affect unoptimized code since comfortable debugging is a prioirty)

I'm cross posting this from the Visual Studio Blog since it affects C++.

Native Unit Test discovery and starting a run take a very long time to complete–many times the length on Visual Studio 2013. Just making one change in one test and then trying to run the test takes several minutes. This is a breaking bug for us. I filed several bugs and am willing to run a profiler to figure out what is causing the issue (deadlock?) but until then I have to go back to Visual Studio 2013 and wait for an update.

1) On an incremental non-optimized builds, this error "fatal error LNK1179: invalid or corrupt file: duplicate COMDAT [obj file reference from a static lib]". Subsequent link attempts complete without issue, even if there is no update to the static lib or recompile of the final target, so I believe all linker inputs should be identical between broken link and functional link.

2) PDB for the debug version of ucrtbase.dll not loading. (Release is "fine".)

this new runtime dll stuff is weird, so much api-ms . dll's + ucrtbase dll in windows 10 ? sorry but this isn't good. just one dll like msvcp140.dll can be easily app locally distributed for all applications, that way all C/C++ programs would run with the right version. Multiple dll's are also fine, but I think app local distrbution is the best way. That way dll hell cannot happen, right dll's are there for the program and one doesn't need redist installed.

Has anyone managed to find a solution for the "The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing…" that doesn't require us to force our customers to do a full Windows Update?