Dimensional Data

We are excited to announce an enhanced Doxygen Comment Support for C++ in Visual Studio 17.7 Preview 2. To start using this feature, ensure to update to the latest version of Visual Studio Preview.   Improved Doxygen overload resolution  Doxygen comment support has been enhanced to improve the visibility and consistency of shared Doxygen comments across all overloads of a function. Previously, these comments were only displayed in Quick Info for the first overload, as shown below.  With this feature improvement, the shared Doxygen comment will now appear in Quick Info of all other overloads as well. This enhancement is demonstrated below.  In cases where the Doxygen comment is not directly positioned above an overload but is applicable to that overload, the Quick Info explicitly indicates this by including the text “Documentation from another overload.” This ensures that you are aware that the information comes from a different overload of the function.  Additionally, the Doxygen comment support now provides improved visibility for unused parameters. The Quick Info categorizes these unused parameters under the “Unused Parameters” section, allowing developers to easily identify which parameters are mentioned in the Doxygen comment but are not utilized in the associated overload.   Send us your feedback!  Try out Improved Doxygen Overload Resolution by downloading the latest version of Visual Studio Preview. We value your feedback, as it greatly influences our development. Please share your thoughts in the comments below, on Developer Community, or reach out to us on Twitter (@VisualC) or via email at visualcpp@microsoft.com. We highly appreciate your inputs!  

Have you ever wanted to try using Windows Subsystem for Linux (WSL) to target Linux from your C++ project, but haven’t gone through the documentation or CLI installation process? Now, from Visual Studio with the Linux and Embedded Workload, Visual Studio makes it easier than ever to get to that one-click install of WSL. Download the latest preview version of Visual Studio and select the Linux and Embedded workload to give it a try! How do I start? n info will open for users to click and open a WSL installation process. By default,   Additionally, you can open the dialog by navigation at any time to Project > Install WSL for me. If you don’t have a WSL machine already installed on your machine, an additional option will be available in your Target Machine dropdown to “Create Linux Environment.” What happens next? Once you click one of these options, an installation dialog will pop up. In the installation dialog, it will automatically check the status of pre-requisites on your machine for the installation and populate additional information if anything needs pre-configuring. You can hover over the question mark icon to learn more information about each pre-requisite check. If any pre-requisite fails, you can follow the error information to fix the errors, and then select “Refresh System Check Values” to re-run the pre-requisite checks. After the pre-requisites are run and all pass, the installation process will kick off. At the end, you can select “Finish” and the new WSL machine with build tools downloaded will be selected as the target machine for your existing CMake project. Coming Soon We will be planning on adding additional tutorial content to open the installer, additional information messaging and customization, and the installer will automatically re-open after reboot of machine. Let us know if there’s anything else you’d like to see! What do you think? We hope this new WSL acquisition experience will help you install and re-target your applications to WSL. Download the latest preview version of Visual Studio and give it a try. Please let us know your thoughts and if you hit any issues! We are actively developing this feature set and would love to hear what would improve your workflow even more. This feature is still fairly new, so please let us know in the comments below or on Visual Studio Feedback if you hit any issues as well. You can also find us on Twitter (@VisualC) or via email at visualcpp@microsoft.com.

Sy Brand June 14th, 20230 2 All of the videos from our Pure Virtual C++ conference are now available! You can find them all on YouTube. Overall we had 18 videos on a wide variety of C++ topics, from Rust/C++ interoperability, to value semantics, to improving compiler errors. Here are the videos for our five live sessions which ran on the day of the conference: Sy Brand C++ Developer Advocate, C++ Team Follow

In preparation for Pure Virtual C++ tomorrow Stephan T. Lavavej has made a video update of all we’ve been working on for conformance in MSVC for C++20 and C++23. You can sign up for Pure Virtual C++ for free here. Stephan’s video is here: Sy Brand C++ Developer Advocate, C++ Team

Interestingly the talks seem all mostly focused on Linux and embedded development. I am missing Windows related C++ development, specially modern tooling for GUI development and modernization of existing Windows SDKs. C++/WinRT is stuck in C++17 without modern Visual Studio tooling on par with C++/CX had, or the competition has in the form of Qt and C++ Builder, and no visible plans to adopt C++20. Windows SDK, DirectX, WDK, WRL, WIL, MFC still have lots of issues being used from C++20 modules. Since BUILD hardly touches C++ content, this would be interesting place to understand where C++ stands for Windows development.

In the last couple of months, the Microsoft C++ team has been working on improving MSVC ARM64 backend performance and we are excited to have a couple of optimizations available in the Visual Studio 2022 version 17.6. These optimizations improved code-generation for both scalar ISA and SIMD ISA (NEON). Let’s review some interesting optimizations in this blog.  Before diving into technical details, we’d encourage you to create feedback here at Developer Community if you have found performance issues. The feedback helps us prioritize work items in our backlog. This, optimize neon right shift into cmp, is an example of good feedback. Including a tagged subject title, detailed description of the issue, and a simple repro simplifies our analysis work and helps us deliver a fix more quickly.  Now, let’s see the optimizations.  Auto-Vectorizer supports more NEON instructions with asymmetric operands The ARM64 backend already supports some NEON instructions with asymmetric typed operands, like Add/Subtract Long operations (SADDL/UADDL/SSUBL/USUBL). These instructions add each vector element in the lower or upper half of the first source SIMD register to the corresponding vector element of the second source SIMD register and write the vector result to the destination SIMD register. The destination vector elements are twice as long as the source vector elements. Now, we have extended such support to Multiply-Add Long and Multiply-Subtract Long (SMLAL/UMLAL/SMLSL/UMLSL).  For example:  void smlal(int * __restrict dst, int * __restrict a,             short * __restrict b, short * __restrict c)  {  for (int i = 0; i < 4; i++)  dst[i] = a[i] + b[i] * c[i];  } In Visual Studio 2022 17.5, the code-generation was:  sxtl        v19.4s,v16.4h  sxtl        v18.4s,v17.4h  mla         v20.4s,v18.4s,v19.4s    Extra signed extensions are performed on both source operands to match the type of destination. Now it has been optimized into a single smlal v16.4s,v17.4h,v18.4h.  The ARM64 ISA further supports another variant for these operations, which is called Add/Subtract Wide. For them, the asymmetry happens between source operands, not between source and destination.  For example:  void saddw(int *__restrict dst, int *__restrict a, short *__restrict b)  {  for (int i = 0; i < 4; i++)  dst[i] = a[i] + b[i];  } In Visual Studio 2022 17.5, the code-generation was:  sxtl        v17.4s,v16.4h  add         v18.4s,v17.4s,v18.4s   The narrow source gets extra signed extension to match the other wide source. In the 17.6 release, this has been optimized into a single saddw v16.4s,v16.4s,v17.4h. The same applies to UADDW/SSUBW/USUBW.  Auto-vectorizer now supports small types on ABS/MIN/MAX  ABS/MIN/MAX have slightly complex semantics. Normally, the compiler middle-end or back-end will have a pattern matcher to recognize IR sequences with if-then-else semantics and see if they could be converted into ABS/MIN/MAX. There is an issue when the operands are in small types (int8 or int16) though.   As specified by the C++ standard, small types are promoted to int, which is 32-bit on ARM64. This is perfect for scalar operations because they really can only operate on scalar register width. For ARM64, the smallest width is 32-bit utilizing the sub-register. However, this is not true for SIMD ISA whose minimum operation width is the width of vector lane (element). For example, ARM64 NEON supports operating on int8, int16 for a couple of operations including ABS/MIN/MAX. So, to generate SIMD instructions operating on small element sizes and deliver higher computing throughput, the auto-vectorizer needs to do […]

As of Visual Studio 2022 version 17.6, the vcpkg C/C++ package manager is included as an installable component for the C++ Desktop and C++ Gaming workloads. You can also find it in the installer by searching for vcpkg package manager under the Individual components tab. Using the Visual Studio Copy of vcpkg After you install or update Visual Studio with the vcpkg component checked, the package manager will be installed in your Visual Studio installation directory. You can run vcpkg commands directly from the Developer Command Prompt for Visual Studio or Developer PowerShell for Visual Studio. This also works for the equivalent consoles embedded in the IDE. vcpkg output is localized according to your Visual Studio language. Both ports and artifacts are supported. As with all copies of vcpkg, to initialize it with the IDE, you will first need to run vcpkg integrate install before running other commands. This will enable MSBuild and CMake IDE integration with this copy of vcpkg. You will need to run this command with administrator privileges. Importantly, the copy of vcpkg that ships with the IDE supports manifests but does not support classic mode. The reason for this is that classic mode requires write access to the vcpkg installation directory, but in this case it is in Program Files and the Visual Studio installer requires ownership of it. You can still use classic mode by running integrate install to an external copy of vcpkg instead. Recap: Existing vcpkg IDE Integration vcpkg was already supported by Visual Studio even before this update. Below is a recap of what you can do with the package manager in the IDE. In order to enable this functionality, you must have run vcpkg integrate install once in the past. Once that is done, you do not need to re-run this command. IntelliSense Support Code calling an external library installed with vcpkg will have working IntelliSense, including autocompletion, semantic colorization, code navigation, and refactoring features. MSBuild Integration There are several MSBuild properties for configuring vcpkg for your project. These are available under Configuration Properties > vcpkg. Importantly, you will want to set “Use Vcpkg Manifest” to “Yes” if you intend to use vcpkg in manifest mode with your MSBuild project. Once this is turned on, if you have a vcpkg.json file in your project, vcpkg will automatically be called every time you do a build to check if any dependencies need to be installed or updated. The package manager will then restore missing dependencies, allowing the build to proceed. CMake Integration The IDE automatically picks up the vcpkg.cmake toolchain file and passes it to the CMake command line behind the scenes, allowing you to use the CMake IDE experience seamlessly. Furthermore, if you have a vcpkg.json manifest file in your project, vcpkg will automatically run when CMake configures itself on project load or when the CMake cache is manually generated. The package manager will automatically install or update any missing dependencies, in accordance with the manifest file, allowing you to build your project successfully. Furthermore, CMake find_package() calls also have IntelliSense autocompletion for various libraries available via vcpkg. Environment Activation with vcpkg Artifacts If you have the Desktop development with C++ or Linux and embedded development workload installed in Visual Studio, you can automatically install and activate tools required for your […]

We’re pleased to announce the availability of C++20 support for C++/CLI in Visual Studio 2022 v17.6. This update to MSVC was in response to feedback received from many customers via votes on Developer Community and otherwise. Thank you! In Visual Studio 2022 v17.6, the use of /clr /std:c++20 will no longer cause the compiler to emit a diagnostic warning that the compiler will implicitly downgrade to /std:c++17. Most C++20 features are supported with the exception of the following: Two-phase name lookup support for managed templates. This is temporarily on hold pending a bugfix. Support for module import under /clr. Both the above are expected to be fixed in a near-future release of MSVC. The remainder of this blog post will discuss the background details, limitations, and caveats of C++20 support for C++/CLI. Brief history and background of C++/CLI C++/CLI was first introduced as an extension to C++98. It was specified as a superset of C++98 but soon with the introduction of C++11, some incompatibilities appeared between C++/CLI and ISO C++, some of which exist to this day. [Aside: nullptr and enum class were originally C++/CLI inventions that were migrated to ISO C++ and standardized.] With the further introduction of C++14 and C++17 standards, it became increasingly challenging to support the newer language standards and eventually due to the effort required to implement C++20, we decided to temporarily limit standard support to C++17 in /clr mode. A prime reason for this was the pause in the evolution of the C++/CLI specification, which has not been updated since its introduction and therefore could not guide the interaction of C++/CLI features with the new features being introduced in ISO C++. The design rationale for C++/CLI is spelled out in this document. Originally envisioned as a first-class language for .NET, C++/CLI’s use has primarily fallen into the category of interop, which includes both directions from managed to native and vice versa. The demise of C++/CLI has been predicted many times, but it continues to thrive in Windows applications primarily because of its strength in interop, where it is very easy to use and hard to beat in performance. The original goals spelled out in the C++/CLI Rationale were: Enable C++/CLI as a first-class programming language on .NET. Use the fewest possible extensions. ISO C++ code “just works” and conforming extensions are added to ISO C++ to allow working with .NET types. Be as orthogonal as possible: if feature X works on ISO C++ types, it should also work on C++/CLI types. With the specialization of C++/CLI as an interop language, the ECMA specification for it was not updated to keep up with fast evolving .NET features with the result that it can no longer be called a first-class language on .NET. While it can consume most of the fundamental types in the .NET base-class library, not all features are available due to lack of support from C++/CLI. This has resulted in both /clr:safe (allow only the “safe” CLS subset of CLI, disallowing native code) and /clr:pure (compile everything to pure MSIL code) to be deprecated. The only options supported currently are /clr, which targets the .NET Framework, and /clr:netcore which targets NetCore. In both cases, compilation of native types and code, and interop are supported. Goal (2) was originally achieved nearly perfectly in C++98 […]

We are happy to announce that Visual Studio 2022 version 17.6 is now generally available! This post summarizes the new features you can find in this release for C++. You can download Visual Studio 2022 from the Visual Studio downloads page or upgrade your existing installation by following the Update Visual Studio Learn page. You’re used to debugging your C++ code with a lot of help from the IDE, but what about your build system? You can use the new CMake Debugger to debug your CMake scripts at configure time. You can set breakpoints based on filenames, line numbers, and when CMake errors are triggered, and can view call stacks of filenames and watch defined variables. Furthermore, the locals window will track CMake variables, targets, and tests. We’ve added a new Remote File Explorer feature. With this you can browse, upload, and download files to your remote machine listed in the Connection Manager, directly from Visual Studio. You can now use the Create Member Function feature to quickly add constructors and equality operators to your classes. When you have a class with member data, three dots will appear under the class name, and hovering over them will display a screwdriver icon. The drop-down from the screwdriver icon will display the new member function suggestions. With this, you can add a default constructor, constructor with all fields, equality operator, and equality operator with all fields.  You can learn more about this feature in our Create C++ Member Function in Visual Studio blog post. We made improvements to the Solution – Close scenario, which makes closing a solution containing C++ projects faster. The overall perf improvements can make closing a solution in some cases from 20% faster for small codebases, to 50% faster in some cases for large solutions (1000+ projects). We expect the wins to be more noticeable in large projects. For Chromium, the improvements are typically 50% faster, saving 20 seconds of time. The Visual Studio Installer now lets you install Incredibuild 10, which comes with a host of new features, including new build cache technology, an improved license management system, and cloud optimization. You can find out more about these features and how you can use them in our Even faster builds with Incredibuild 10 and Visual Studio 17.6 Preview 3 blog post. We have added initial support for C++20 mode in C++/CLI projects. All C++20 headers can be #included in a /clr compilation without restrictions. You can find out more details in our C++20 Support for C++/CLI blog post. We continue to work on C++23 support in our standard library, as well as improving our support for existing standards. Many of these features have been contributed by you folks in the community: thank you! You can find the full changelist on the Microsoft STL GitHub page. Here are some highlights: P1223R5 ranges::find_last, ranges::find_last_if, ranges::find_last_if_not P2321R2 views::zip_transform P2474R2 views::repeat P2505R5 Monadic Functions for expected Activated the vectorized implementations of find(), count(), ranges::find(), and ranges::count() for more scenarios involving pointer elements. Added visualizers for error_category and error_code. Improved the output of source_location::function_name(). It now includes both function parameter types and template arguments. Visual Studio 2022 version 17.6 comes with built-in support for HLSL and a new tool to view Unreal Engine logs. HLSL (High Level Shading Language) is a DirectX-specific programming language used to create shaders in game development and rendering applications. The popular HLSL Tools extension by […]

The Makefile Tools team in VS Code has shipped the latest 0.7.0 version of the extension. In this version, we have enabled variable expansion for your Makefile projects in settings, so you no longer need to write plain paths for your Makefiles in the settings.json for the extension and can instead utilize variables that the Makefile extension can detect and replace values for. This allows for easier sharing of settings.json and improved consistency. Also, this allows for parameterization, so that you can define one setting and don’t need to constantly change its value if you toggle between different configurations and/or build targets.  We have also improved the user experience for when Makefile, Make and build.log are not found and added new support for C++23. The details of all that is new with this release can be found here in this change log.  Variable Expansion The macros that are now supported to work from any setting entry-point are:  ${workspaceFolder} and  ${workspaceRoot} ${workspaceFolderBasename}  ${userHome}  ${env:ENVIRONMENT_VARIABLE}  ${config:ANY_EXTENSION_SCOPE.ANY_SETTING_ID}  ${command:ANY_EXTENSION_SCOPE.ANY_COMMAND_ID}  ${configuration} and  ${command:makefile.getConfiguration} ${buildTarget} and  ${command:makefile.getBuildTarget} You can use this syntax in your settings.json, and the Makefile extension will automatically detect and populate the relevant information for these variables. Below are a few examples of using these macros to substitute your existing plain text. Variable Example Expanded Variable Example “makefile.extensionOutputFolder”: “${userHome}/MyOutput/${workspaceFolderBasename}”  C:/Users/Public/MyOutput/MyProject  “makefile.makePath”: “${env:ProgramFiles(x86)}/GnuWin32/bin/make.exe”  C:/Program Files (x86)/GnuWin32/bin/make.exe  “makefile.extensionLog”: “extension_${configuration}_${buildTarget}.log”  extension_debug_x86.log   “makefile.configurationCachePath”: “cache_${command:makefile.getConfiguration}_${command:makefile.getBuildTarget}.log”  cache_debug_x86.log   “makefile.compileCommandsPath”: “${config:C_Cpp.default.compileCommands}”  C:/github/projects/MyProject/build/compile_commands.json  “makefile.makefilePath”: “${workspaceFolder}/Makefiles/makefile.in”  C:/github/projects/MyProject/Makefiles/makefile.in  “makefile.launchConfigurations”:{[…        “binaryPath”: “${workspaceRoot}/test.exe”,       “binaryArgs”: [\${buildTarget}, “${buildTarget}”]  …]}  test.exe ${buildTarget} x86 Improved messaging when Makefile, Make and Build.log are not found  Now, you can see the status of all critical components used in activating the extension in the left–side Makefile Tools project outline including the newly added Makefile, Make, and Build Log. Makefile, Make, and Build.log are not found, the extension has a “not found” status integrated into this side panel next to each item.   in the latest pre-release version, you can specify the path to these files so that the extension can find them and activate all capabilities fully as well as show the current status of the project. Once you select a path for each item, you can view the active path and status in the side panel.  We have also set up a pre-release pipeline, so you can get earlier access before an official release ship to any bug fixes and releases that users merge to the Makefile Tools repository. All you need to do is click the “Switch to Pre-Release version” under the Makefile Tools extension.  Some new functionality is available in the latest pre-release, including the ability to open Makefile and Build Log using new buttons in the project outline.  Future Work Next, we will be investigating some of your most highly up-support for multi-root repositories.  What do you think? Download the Makefile Tools extension for Visual Studio Code today, give the latest version a try, and let us know what you think. Check out our README documentation to learn more about activating the extension and getting started.  If you run into any issues, or have any suggestions, please report them in the Issues section of our GitHub repository.  We can be reached via the comments below or in email at VisualC@microsoft.com. You can also find our team on Twitter at  @VisualC.