Dimensional Data

We are excited to announce that Create C++ Member Function can now be used to quickly add constructor and in Visual Studio 17.6 Preview 2. When you have a class with fields, you can add a default constructor, constructor with all fields, equality operator, and . Three dots will appear below a class name to indicate that you can add a member function, and you can hover over them to see the quick action (screwdriver icon). When the default constructor and equality operator are added respectively, the Go to Definition of the operator== is displayed below, showing that the body of the   You can also choose to add a constructor with all fields and an equality operator with all fields respectively, and the Go to Definition will show that the operator== has all the field comparisons.     Future Work This experimental feature will be improved by adding more functions that can save you a lot of typing. Right now, it includes constructor and operator==and we are considering adding more cases,   We have a Developer Community ticket to Improve “Create Member Function”, if you have the same suggestions make sure to upvote it.   Send us your feedback!  Download the latest version of Visual Studio Preview and give the Create C++ Member Function feature a try. Your feedback will be extremely helpful in shaping this experience, therefore, please continue to send your feedback in the comments below or/and via Developer Community. You can also reach us on Twitter (@VisualC), or via email at visualcpp@microsoft.com.   

C++20 added new versions of the standard library algorithms which take ranges as their first argument rather than iterator pairs, alongside other improvements. However, key algorithms like std::accumulate were not updated. This has been done in C++23, with the new std::ranges::fold_* family of algorithms. The standards paper for this is P2322 and was written by Barry Revzin. It been implemented in Visual Studio 2022 version 17.5. In this post I’ll explain the benefits of the new “rangified” algorithms, talk you through the new C++23 additions, and explore some of the design space for fold algorithms in C++. Background: Rangified Algorithms C++20’s algorithms make several improvements to the old iterator-based ones. The most obvious is that they now can take a range instead of requiring you to pass iterator pairs. But they also allow passing a “projection function” to be called on elements of the range before being processed, and the use of C++20 concepts for constraining their interfaces more strictly defines what valid uses of these algorithms are. These changes allow you to make refactors like: // C++17 algorithm cat find_kitten(const std::vector& cats) { return *std::find_if(cats.begin(), cats.end(), [](cat const& c) { return c.age == 0; }); } // C++20 algorithm cat find_kitten(std::span cats) { return *std::ranges::find(cats, 0, &cat::age); } The differences here are: Instead of having to pass cats.begin() and cats.end(), we just pass cats itself. Since we are comparing a member variable of the cat to 0, in C++17 we need to use std::find_if and pass a closure which accesses that member and does the comparison. Since the rangified algorithms support projections, in C++20 we can use std::ranges::find and pass &cat::age as a projection, getting rid of the need for the lambda completely. These improvements can greatly clean up code which makes heavy use of the standard library algorithms. Unfortunately, alongside the algorithms which reside in the header, there are also several important ones in the header, and these were not rangified in C++201. In this post we’re particularly interested in std::accumulate and std::reduce. accumulate and reduce std::accumulate and std::reduce are both fold operations. They “fold” or “reduce” or “combine” multiple values into a single value. Both take two iterators, an initial value, and a binary operator (which defaults to +). They then run the given operator over the range of values given by the iterators, collecting a result as they go. For instance, given std::array arr = {1,2,3}, std::accumulate(begin(arr), end(arr), 0, std::plus()) will run (((0 + 1) + 2) + 3). Or std::accumulate(begin(arr), end(arr), 0, f) will run f(f(f(0, 1), 2), 3). These functions are both what are called left folds because they run from left to right. There’s also right folds, which as you may guess, run from right to left. For the last example a right fold would look like f(1, f(2, f(3, 0))). For some operations, like +, these would give the same result, but for operations which are not associative (like -), it could make a difference. So why do we have both std::accumulate and std::reduce? std::reduce was added in C++17 as one of the many parallel algorithms which let you take advantage of parallel execution for improved performance. The reason it has a different name than std::accumulate is because it has different constraints on what types and operations you can use: namely the […]

This post is an updated version of one I made over five years ago, now that everything I talked about is in the standard and implemented in Visual Studio. In software things can go wrong. Sometimes we might expect them to go wrong. Sometimes it’s a surprise. In most cases we want to build in some way of handling these misfortunes. Let’s call them disappointments. std::optional was added in C++17 to provide a new standard way of expressing disappointments and more, and it has been extended in C++23 with a new interface inspired by functional programming. std::optional expresses “either a T or nothing”. C++23 comes with a new type, std::expected which expresses “either the expected T, or some E telling you what went wrong”. This type also comes with that special new functional interface. As of Visual Studio 2022 version 17.6 Preview 3, all of these features are available in our standard library. Armed with an STL implementation you can try yourself, I’m going to exhibit how to use std::optional‘s new interface, and the new std::expected to handle disappointments. One way to express and handle disappointments is exceptions: void pet_cat() { try { auto cat = find_cat(); scratch_behind_ears(cat); } catch (const no_cat_found& err) { //oh no be_sad(); } } There are a myriad of discussions, resources, rants, tirades, and debates about the value of exceptions123456, and I will not repeat them here. Suffice to say that there are cases in which exceptions are not the best tool for the job. For the sake of being uncontroversial, I’ll take the example of disappointments which are expected within reasonable use of an API. The Internet loves cats. Suppose that you and I are involved in the business of producing the cutest images of cats the world has ever seen. We have produced a high-quality C++ library geared towards this sole aim, and we want it to be at the bleeding edge of modern C++. A common operation in feline cutification programs is to locate cats in a given image. How should we express this in our API? One option is exceptions: // Throws no_cat_found if a cat is not found. image_view find_cat (image_view img); This function takes a view of an image and returns a smaller view which contains the first cat it finds. If it does not find a cat, then it throws an exception. If we’re going to be giving this function a million images, half of which do not contain cats, then that’s a lot of exceptions being thrown. In fact, we’re pretty much using exceptions for control flow at that point, which is A Bad Thing™. What we really want to express is a function which either returns a cat if it finds one, or it returns nothing. Enter std::optional. std::optional find_cat (image_view img); std::optional was introduced in C++17 for representing a value which may or may not be present. It is intended to be a vocabulary type — i.e. the canonical choice for expressing some concept in your code. The difference between this signature and the previous one is powerful; we’ve moved the description of what happens on an error from the documentation into the type system. Now it’s impossible for the user to forget to read the docs, because the compiler is reading them for us, […]

The team has been working hard to provide new highly requested capabilities for CMake users. Now, in version 1.14, we have provided a new Test Explorer for using CTest with your CMake projects. This release also features open-source community contributions from users. Thanks for your contributions! Test Explorer One of our most highly-upvoted tickets in the CMake Tools Extension was the request for a Test Explorer for CTest. We are excited to announce that this is now available for users in the latest version of the CMake Tools extension in VS Code. Now, in your CMake projects, you can click the “Run CTest” icon along the bottom status bar or the “Testing” side panel icon to launch the test explorer. When the project is configured, the tests in your CMakeLists.txt will load in the Test Explorer. In the Test Explorer, you can view the detailed state of all your tests and the last results of these test runs. By clicking on the play button, you can run a specific test (or set of tests). Also, by clicking on the debug play button, you can debug these tests. Using the topmost icon, you can view the output of these tests. You can refresh these tests at any time using the refresh icon up top. We are continuing to listen to and work on all feedback we receive on the Test Explorer, so if you have any issues or suggestions, please report them in the Issues section of our GitHub repository. Future Work Next up, we are planning to experiment with the CMake tools user experience settings and implement CMake language services and a CMake Debugger. Is there anything else you’d like to see? Let us know! What do you think? Download the CMake Tools extension for Visual Studio Code and let us know what you think. We would love to see what you contribute to our repo and are active on reviews and collaboration. Comment below or reach us via email at visualcpp@microsoft.com or via Twitter at @VisualC.