{"id":7967,"date":"2023-08-07T06:06:38","date_gmt":"2023-08-07T06:06:38","guid":{"rendered":"https:\/\/www.modernescpp.com\/?p=7967"},"modified":"2023-08-23T17:00:15","modified_gmt":"2023-08-23T17:00:15","slug":"c23-more-small-pearls","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c23-more-small-pearls\/","title":{"rendered":"C++23: More Small Pearls"},"content":{"rendered":"\n

With the static multidimensional subscript and call operator, the C++23 core language has more to offer.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

auto(x)<\/code> and auto{x}<\/code><\/h2>\n\n\n\n

In my last post, “C++23: The Small Pearls in the Core Language<\/a>“, I gave a concise explanation of auto(x) <\/code>and auto{x}<\/code>: The calls auto(x) <\/code>and auto{x}<\/code> cast x<\/code> into a prvalue as if passing x<\/code> as a function argument by value. auto(x)<\/code> and auto{x}<\/code> perform a decay copy. I also explained a decay copy. This explanation of auto(x)<\/code> and auto{x}<\/code> was short, too short. <\/p>\n\n\n\n

Ga\u0161per A\u017eman<\/a> tweeted me about it:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Ga\u0161per is an active member of the C++ standardization committee: In C++, he participated in the standardization of “deducing this”<\/a>, and “using enum<\/a>“. Additionally, Ga\u0161per is involved in the customization points <\/a>effort, the contracts<\/a> effort, and is an assistant chair of the networking study group.<\/p>\n\n\n\n

I asked Ga\u0161per if he wants to write a few words about the implications of auto(x)<\/code> and auto{x}<\/code> on function interface design. I’m happy to present his answer. The explanation is embedded into the source code.<\/p>\n\n\n\n

#include <vector><\/span>\n#include <string><\/span>\n#include <memory><\/span>\n#include <utility><\/span>\n#include <array><\/span>\n#include <algorithm><\/span>\n#include <charconv><\/span>\n#include <cstring><\/span>\n#include <iostream><\/span>\n\n\n\/\/ To achieve a design that improves local reasoning, we should<\/span>\n\/\/ design algorithm interfaces to not mutate their arguments if<\/span>\n\/\/ at all possible.<\/span>\n\/\/ Unfortunately, this is often at odds with the efficiency of<\/span>\n\/\/ the implementation of the algorithm.<\/span>\n\n\/\/ This comes up in many areas. A few examples include:<\/span>\n\/\/ - matrix algorithms, where implementations often require that arguments do not alias<\/span>\n\/\/ - state machines, where testing is far easier if we can produce a completely new state<\/span>\n\/\/ - range algorithms such as the below example<\/span>\n\/\/ - immutable maps and sets (see the immer library: https:\/\/github.com\/arximboldi\/immer)<\/span>\n\n\/\/ For clarity, let us consider a small example.<\/span>\n\/\/ Our data structure will be a vector of integers<\/span>\n\/\/ Our family of algorithms will be "sorted" and "uniqued"<\/span>\n\n\/\/ In c++20 (if we ignore ranges - we are trying to illustrate an approach),<\/span>\n\/\/ we would probably design the interface by taking by value and returning<\/span>\n\/\/ by value<\/span>\n\n\/\/ (helpers)<\/span>\nauto<\/span> read_input(int<\/span> argc, char<\/span>**<\/span> argv) -><\/span> std::<\/span>vector<<\/span>int<\/span>><\/span>;\nauto<\/span> write_output(int<\/span>) -><\/span> void<\/span>;\n\nnamespace<\/span> traditional {\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\nauto<\/span> sorted(std::<\/span>vector<<\/span>T><\/span> x) -><\/span> std::<\/span>vector<<\/span>T><\/span> {\n    std::<\/span>sort(x.begin(), x.end());\n    return<\/span> x;\n}\n\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\nauto<\/span> uniqued(std::<\/span>vector<<\/span>T><\/span> x) -><\/span> std::<\/span>vector<<\/span>T><\/span> {\n    x.erase(std::<\/span>unique(x.begin(), x.end()), x.end());\n    return<\/span> x;\n}\n\n\/\/ This pattern leads to the following usage pattern<\/span>\nauto<\/span> usage(int<\/span> argc, char<\/span>**<\/span> argv) {\n    for<\/span> (auto<\/span> i :<\/span> uniqued(sorted(read_input(argc, argv)))) {\n        write_output(i);\n    };\n}\n\n\/\/ This is good, but sooner or later someone will want to refactor this<\/span>\n\/\/ code like this<\/span>\nauto<\/span> refactor(int<\/span> argc, char<\/span>**<\/span> argv) {\n    auto<\/span> input =<\/span> read_input(argc, argv);\n    for<\/span> (auto<\/span> i :<\/span> uniqued(sorted(input))) {\n        write_output(i);\n    };\n}\n\n\/\/ can you spot the bug? Non-professionals often don't!<\/span>\n\/\/ If you work with researchers and scientists, this kind of mistake<\/span>\n\/\/ is ubiquitous, and leads to serious, serious slow-downs that are often<\/span>\n\/\/ difficult to find if not spotted immediately.<\/span>\n\n\/\/ What can we do? We should ask the compiler to issue an error, of course.<\/span>\n\/\/ We can do this by explicitly asking for an rvalue reference instead of <\/span>\n\/\/ taking by value.<\/span>\n}\n\nnamespace<\/span> require_moves {\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\nauto<\/span> sorted(std::<\/span>vector<<\/span>T>&&<\/span> x) -><\/span> std::<\/span>vector<<\/span>T><\/span> {\n    \/\/                    ^^ new<\/span>\n    std::<\/span>sort(x.begin(), x.end());\n    return<\/span> x;\n}\n\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\nauto<\/span> uniqued(std::<\/span>vector<<\/span>T>&&<\/span> x) -><\/span> std::<\/span>vector<<\/span>T><\/span> {\n    \/\/                     ^^ new<\/span>\n    x.erase(std::<\/span>unique(x.begin(), x.end()), x.end());\n    return<\/span> x;\n}\nauto<\/span> read_input(int<\/span> argc, char<\/span>**<\/span> argv) -><\/span> std::<\/span>vector<<\/span>int<\/span>><\/span>;\nauto<\/span> write_output(int<\/span>) -><\/span> void<\/span>;\n\nauto<\/span> usage<\/span>(int<\/span> argc, char<\/span>**<\/span> argv) {\n    \/\/ compiles unchanged, and has the same performance<\/span>\n    for<\/span> (auto<\/span> i :<\/span> uniqued(sorted(read_input(argc, argv)))) {\n        write_output(i);\n    };\n}\n\nauto<\/span> refactor<\/span>(int<\/span> argc, char<\/span>**<\/span> argv) {\n    auto<\/span> input =<\/span> read_input(argc, argv);\n    for<\/span> (auto<\/span> i :<\/span> uniqued(sorted(std::<\/span>move(input)))) {\n        \/\/                       ^^^^^^^^^^     ^ required, does not compile without it!<\/span>\n        write_output(i);\n    };\n}\n\nauto<\/span> print_diff(std::<\/span>vector<<\/span>int<\/span>><\/span> const<\/span>&<\/span>, std::<\/span>vector<<\/span>int<\/span>><\/span> const<\/span>&<\/span>) -><\/span> void<\/span>;\n\n\/\/ of course, now we have a problem. What if we actually needed the copy?<\/span>\n#if defined(TRY_1)<\/span>\nauto<\/span> check_is_sorted_and_uniqued<\/span>(int<\/span> argc, char<\/span>**<\/span> argv) {\n    auto<\/span> input =<\/span> read_input(argc, argv);\n    auto<\/span> sorted_and_uniqued =<\/span> uniqued(sorted(input));\n    \/\/                                ^^^^^^ no matching function for call to sorted<\/span>\n    if<\/span> (input !=<\/span> sorted_and_uniqued) {\n        print_diff(input, sorted_and_uniqued);\n        exit(1<\/span>);\n    }\n    exit(0<\/span>);\n}\n#elif defined(TRY_2)<\/span>\n\/\/ we can work around this by making a copy explicitly<\/span>\nauto<\/span> check_is_sorted_and_uniqued<\/span>(int<\/span> argc, char<\/span>**<\/span> argv) {\n    auto<\/span> input =<\/span> read_input(argc, argv);\n    auto<\/span> input_copy =<\/span> input; \/\/ <- sad face; requires its own statement, ugly<\/span>\n    auto<\/span> sorted_and_uniqued =<\/span> uniqued(sorted(std::<\/span>move(input_copy)));\n    if<\/span> (input !=<\/span> sorted_and_uniqued) {\n        print_diff(input, sorted_and_uniqued);\n        exit(1<\/span>);\n    }\n    exit(0<\/span>);\n}\n\/\/ Don't you think this is bad user experience, though?<\/span>\n\/\/ Of course it is. We just wanted to make copies explicit, not near-impossible.<\/span>\n\/\/ The standard library specification has had a name for this for a long time:<\/span>\n\/\/ they call it DECAY_COPY, which is literally what happens, but is inscruitable<\/span>\n\/\/ jargon.<\/span>\n#elif defined(TRY_3)<\/span>\n\/\/ Some smart users have tried and defined their own accompanying function<\/span>\n\/\/ to std::move for this:<\/span>\nauto<\/span> decay_copyish<\/span>(auto<\/span>&&<\/span> x) { return<\/span> std::<\/span>forward<<\/span>decltype(x)><\/span>(x); }\n\n\/\/ If we have that, we could write our check_is_sorted_and_uniqued without the named copy:<\/span>\nauto<\/span> check_is_sorted_and_uniqued<\/span>(int<\/span> argc, char<\/span>**<\/span> argv) {\n    auto<\/span> input =<\/span> read_input(argc, argv);\n    auto<\/span> sorted_and_uniqued =<\/span> uniqued(sorted(decay_copy(input)));\n    \/\/                                       ^^^^^^^^^^ "explicit" copy<\/span>\n    if<\/span> (input !=<\/span> sorted_and_uniqued) {\n        print_diff(input, sorted_and_uniqued);\n        exit(1<\/span>);\n    }\n    exit(0<\/span>);\n}\n\n\/\/ This works, and in this case is optimal, but leaves something to be desired in generic cases.<\/span>\n\/\/ Let us try and see what happens if we try and refactor sort+unique into a generic<\/span>\n\/\/ algorithm<\/span>\n\n#endif<\/span>\n\/\/ Let's take our vector as a forwarding reference so we can reuse its memory if we own it<\/span>\n\/\/ We need a concept for that<\/span>\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\ninline<\/span> constexpr bool<\/span> is_vector_v =<\/span> false<\/span>;\ntemplate<\/span> <<\/span>typename<\/span> T, typename<\/span> A><\/span>\ninline<\/span> constexpr bool<\/span> is_vector_v<<\/span>std::<\/span>vector<<\/span>T, A>><\/span> =<\/span> true<\/span>;\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\nconcept a_vector =<\/span> is_vector_v<<\/span>std::<\/span>remove_cvref_t<\/span><<\/span>T>><\/span>;\n\n\/\/ we take this by forwarding reference; but now,<\/span>\n\/\/ we make an additional move-construction if v is passed by rvalue reference<\/span>\nauto<\/span> sorted_and_uniqued<\/span>(a_vector auto<\/span>&&<\/span> v) {\n    return<\/span> uniqued(sorted(decay_copy(std::<\/span>forward<<\/span>decltype(v)><\/span>(v))));\n    \/\/                    ^^^^^^^^^^ an extra move construction or the needed copy-construction<\/span>\n    \/\/ specifically, we move-construct decay_copy's return value.<\/span>\n}\n\n\/\/ so, decay_copy is clearly not optimal. We need something that won't result<\/span>\n\/\/ in additional move-constructions and still accomplish our "copies are explicit" goal.<\/span>\n\n\/\/ enter: decay-copy in the language!<\/span>\n}\n\nnamespace<\/span> done_properly {\nusing<\/span> require_moves::<\/span>sorted, require_moves::<\/span>uniqued, require_moves::<\/span>a_vector, require_moves::<\/span>print_diff;\n\n\/\/ in regular user code, we can now use auto{} instead of decay-copy:<\/span>\nauto<\/span> check_is_sorted_and_uniqued<\/span>(int<\/span> argc, char<\/span>**<\/span> argv) {\n    auto<\/span> input =<\/span> read_input(argc, argv);\n    auto<\/span> sorted_and_uniqued =<\/span> uniqued(sorted(auto<\/span>(input)));\n    \/\/                                       ^^^^^^^^^^^ explicit copy<\/span>\n    if<\/span> (input !=<\/span> sorted_and_uniqued) {\n        print_diff(input, sorted_and_uniqued);\n        exit(1<\/span>);\n    }\n    exit(0<\/span>);\n}\n\n\/\/ in generic contexts<\/span>\nauto<\/span> sorted_and_uniqued<\/span>(a_vector auto<\/span>&&<\/span> v) {\n    return<\/span> uniqued(sorted(auto<\/span>(std::<\/span>forward<<\/span>decltype(v)><\/span>(v))));\n    \/\/                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<\/span>\n    \/\/ correct forwarded copy of an argument we took by forwarding reference<\/span>\n}\n}\n\n\/\/ Thanks for reading!<\/span>\n<\/pre><\/div>\n\n\n\n
Multidimensional Subscript Operator<\/h2>\n\n\n\n
Thanks to std::mdspan<\/code>, C++23 supports multi-dimensional arrays. The C++23 core language also supports a multidimensional subscript operator to complete the feature.<\/p>\n\n\n\n
\/\/ multidimensionalSubscript.cpp<\/span>\n\n#include <array><\/span>\n#include <iostream><\/span>\n \ntemplate<\/span><<\/span>typename<\/span> T, std::<\/span>size_t<\/span> X, std::<\/span>size_t<\/span> Y><\/span>\nstruct<\/span> Matrix {\n    std::<\/span>array<<\/span>T, X *<\/span> Y><\/span> mat{};\n \n    T&<\/span> operator<\/span>[](std::<\/span>size_t<\/span> x, std::<\/span>size_t<\/span> y) {               \/\/ (1)<\/span>\n        return<\/span> mat[y *<\/span> X +<\/span> x];\n    }\n};\n \nint<\/span> main<\/span>() {\n\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n\n    Matrix<<\/span>int<\/span>, 3<\/span>, 3<\/span>><\/span> mat;\n    for<\/span> (auto<\/span> i :<\/span> {0<\/span>, 1<\/span>, 2<\/span>}) {\n        for<\/span> (auto<\/span> j :<\/span> {0<\/span>, 1<\/span>, 2<\/span>}) mat[i, j] =<\/span> (i *<\/span> 3<\/span>) +<\/span> j;       \/\/ (2)<\/span>\n    }\n    for<\/span> (auto<\/span> i :<\/span> {0<\/span>, 1<\/span>, 2<\/span>}) {\n        for<\/span> (auto<\/span> j :<\/span> {0<\/span>, 1<\/span>, 2<\/span>}) std::<\/span>cout <<<\/span> mat[i, j] <<<\/span> " "<\/span>; \/\/ (3)<\/span>\n    }\n\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n\n}\n<\/pre><\/div>\n\n\n\n
Line (1) defines the two-dimensional subscript operator for the class Matrix<\/code>. Line (2) uses it to define the elements, and line (3) reads them.  <\/p>\n\n\n\n
Here is the output of the program:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
static operator ()<\/code> and operator []<\/code><\/h2>\n\n\n\n
With C++23, the call operator()<\/code> and the multi-dimensional subscript operator []<\/code> can be static. You may ask, why? The answer is typical for C++: optimization<\/p>\n\n\n\n
Optimization<\/h3>\n\n\n\n
The implicit this <\/code>pointer must be passed around in an extra register if a member function cannot be inlined. Thanks to a static member function, you can spare the this <\/code>pointer. Also, lambdas, which do not capture anything, can be static <\/code>in C++23:<\/p>\n\n\n\n
auto<\/span> sum =<\/span> [](auto<\/span> a, auto<\/span> b) static<\/span> {return<\/span> a +<\/span> b;};\n<\/pre><\/div>\n\n\n\n
For consistency reasons, the multi-dimensional subscript operator []<\/code> can also be static. <\/p>\n\n\n\n
\/\/ multidimensionalSubscriptStatic.cpp<\/span>\n\n#include <array><\/span>\n#include <iostream><\/span>\n \ntemplate<\/span><<\/span>typename<\/span> T, std::<\/span>size_t<\/span> X, std::<\/span>size_t<\/span> Y><\/span>\nstruct<\/span> Matrix {\n\n    static<\/span> inline<\/span> std::<\/span>array<<\/span>T, X *<\/span> Y><\/span> mat{};               \/\/ (2)<\/span>\n    \n    static<\/span> T&<\/span> operator<\/span>[](std::<\/span>size_t<\/span> x, std::<\/span>size_t<\/span> y) {    \/\/ (1)<\/span>\n        return<\/span> mat[y *<\/span> X +<\/span> x];\n    }\n};\n\n \nint<\/span> main<\/span>() {\n\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n\n    Matrix<<\/span>int<\/span>, 3<\/span>, 3<\/span>><\/span> mat;\n    for<\/span> (auto<\/span> i :<\/span> {0<\/span>, 1<\/span>, 2<\/span>}) {\n        for<\/span> (auto<\/span> j :<\/span> {0<\/span>, 1<\/span>, 2<\/span>}) mat[i, j] =<\/span> (i *<\/span> 3<\/span>) +<\/span> j;\n    }\n    for<\/span> (auto<\/span> i :<\/span> {0<\/span>, 1<\/span>, 2<\/span>}) {\n        for<\/span> (auto<\/span> j :<\/span> {0<\/span>, 1<\/span>, 2<\/span>}) std::<\/span>cout <<<\/span> mat[i, j] <<<\/span> " "<\/span>;  \n    }\n\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\n\n}\n<\/pre><\/div>\n\n\n\n
Now, the two-dimensional subscript operator []<\/code> (line 1) and the std::array mat <\/code>(line 2) are static<\/code>. <\/p>\n\n\n\n
What’s next? <\/h2>\n\n\n\n
My next post will be a guest post by Victor Duvanenko. He provides exhaustive performance numbers about my favorite C++17 feature: the parallel STL algorithms.<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
With the static multidimensional subscript and call operator, the C++23 core language has more to offer. auto(x) and auto{x} In my last post, “C++23: The Small Pearls in the Core Language“, I gave a concise explanation of auto(x) and auto{x}: The calls auto(x) and auto{x} cast x into a prvalue as if passing x as […]<\/p>\n","protected":false},"author":21,"featured_media":7969,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[378],"tags":[436],"class_list":["post-7967","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-c-23","tag-auto"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/7967","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=7967"}],"version-history":[{"count":22,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/7967\/revisions"}],"predecessor-version":[{"id":8034,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/7967\/revisions\/8034"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/7969"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=7967"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=7967"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=7967"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Here is more information about how to pass function parameters: C++ Core Guidelines: The Rules for in, out, in-out, consume, and forward Function Parameter<\/a>.<\/p>\n\n\n\n