{"id":5967,"date":"2020-08-13T10:37:34","date_gmt":"2020-08-13T10:37:34","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/new-attributes-with-c-20\/"},"modified":"2020-08-13T10:37:34","modified_gmt":"2020-08-13T10:37:34","slug":"new-attributes-with-c-20","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/new-attributes-with-c-20\/","title":{"rendered":"New Attributes with C++20"},"content":{"rendered":"

With C++20, we got new and improved attributes such as [[nodiscard(“reason”)]]<\/span>, [[likely]]<\/span>, [[unlikely]]<\/span>, and [[no_unique_address]]<\/span>. In particular, [[nodiscard(“reason”)]]<\/span> allows it to express the intention of your interface way clearer.<\/p>\n

<\/p>\n

 \"TimelineCpp20CoreLanguage\"<\/p>\n

Attributes allow it to express declaratively the intention of your code.<\/p>\n

New Attributes<\/h2>\n

During the writing of this article, I become a big fan of [[nodiscard(“reason”)]]<\/span>. Consequently, I want to start with my favorite.<\/p>\n

[[nodiscard(“reason”)]]<\/span><\/h3>\n

We have [[nodiscard]]<\/span> already since C++17. C++20 added the possibility to add a message to the attribute. Unfortunately, I ignored [[nodiscard]]<\/span> in the last few years. Let me present it now. Imagine, I have the following program.<\/p>\n

 <\/p>\n

\n
\/\/ withoutNodiscard.cpp<\/span>\r\n\r\n#include <utility><\/span>\r\n\r\nstruct<\/span> MyType {\r\n\r\n     MyType(int<\/span>, bool<\/span>) {}\r\n\r\n};\r\n\r\ntemplate<\/span> <<\/span>typename<\/span> T, typename<\/span> ... Args><\/span>\r\nT*<\/span> create(Args&&<\/span> ... args){\r\n  return<\/span> new<\/span> T(std::<\/span>forward<<\/span>Args><\/span>(args)...);\r\n\r\nenum<\/span> class<\/span> ErrorCode<\/span> {\r\n    Okay,\r\n    Warning,\r\n    Critical,\r\n    Fatal\r\n};\r\n\r\nErrorCode errorProneFunction<\/span>() { return<\/span> ErrorCode::<\/span>Fatal; }\r\n\r\nint<\/span> main<\/span>() {\r\n\r\n    int<\/span>*<\/span> val =<\/span> create<<\/span>int<\/span>><\/span>(5<\/span>);\r\n    delete<\/span> val;\r\n\r\n    create<<\/span>int<\/span>><\/span>(5<\/span>);         \/\/ (1)<\/span>\r\n\r\n    errorProneFunction();   \/\/ (2)<\/span>\r\n    \r\n    MyType(5<\/span>, true<\/span>);        \/\/ (3)<\/span>\r\n\r\n} \r\n<\/pre>\n<\/div>\n
 <\/p>\n
Thanks to perfect forwarding and parameter packs, the factory function create<\/span> can call any constructor and return a heap-allocated object.<\/p>\n
The program has many issues. First, line (1) has a memory leak because the heap created int<\/span> is never destroyed. Second, the error code of the function errorPronceFunction<\/span> (2) is not checked. Last, the constructor call MyType(5, true)<\/span> creates a temporary, which is created and immediately destroyed. This is at least a waste of resources. Now, [[nodiscard]]<\/span> comes into play.<\/p>\n
[[nodiscard]] <\/span>can be used in a function, enumeration, or class declaration. If you discard the return value from a function declared as nodiscard, the compiler should issue a warning. The same holds for a function returning by copy an enumeration or a class declared as [[nodiscard]]<\/span>. A cast-to-void should not emit a warning.<\/p>\n
Let me see what this means. In the following example, I use the C++17 syntax of the attribute [[nodiscard]]<\/span>.<\/p>\n
 <\/p>\n
\n
\/\/ nodiscard.cpp<\/span>\r\n\r\n#include <utility><\/span>\r\n\r\nstruct<\/span> MyType {\r\n\r\n     MyType(int<\/span>, bool<\/span>) {}\r\n\r\n};\r\n\r\ntemplate<\/span> <<\/span>typename<\/span> T, typename<\/span> ... Args><\/span>\r\n[[nodiscard]]\r\nT*<\/span> create(Args&&<\/span> ... args){\r\n  return<\/span> new<\/span> T(std::<\/span>forward<<\/span>Args><\/span>(args)...);\r\n}\r\n\r\nenum<\/span> class<\/span> [[nodiscard<\/span>]] ErrorCode {\r\n    Okay,\r\n    Warning,\r\n    Critical,\r\n    Fatal\r\n};\r\n\r\nErrorCode errorProneFunction<\/span>() { return<\/span> ErrorCode::<\/span>Fatal; }\r\n\r\nint<\/span> main<\/span>() {\r\n\r\n    int<\/span>*<\/span> val =<\/span> create<<\/span>int<\/span>><\/span>(5<\/span>);\r\n    delete<\/span> val;\r\n\r\n    create<<\/span>int<\/span>><\/span>(5<\/span>);         \/\/ (1)<\/span>\r\n\r\n    errorProneFunction();   \/\/ (2)<\/span>\r\n    \r\n    MyType(5<\/span>, true<\/span>);        \/\/ (3)<\/span>\r\n\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The factory function create<\/span> and the enum ErrorCode<\/span> is declared as [[nodiscard]]<\/span>. Consequently, calls (1) and (2) create a warning.<\/p>\n
\"nodiscard\"<\/p>\n
 <\/p>\n
Way better, but the program still has a few issues.  [[nodiscard]]<\/span> cannot be used for functions such as a constructor returning nothing. Therefore, the temporary MyType(5, true)<\/span> is still created without warning. Second, the error messages are too general. As a user of the functions, I want a reason why discarding the result is an issue.<\/p>\n
Both issues can be solved with C++20. Constructors can be declared as [[nodiscard]]<\/span>, and the warning could have additional information.<\/p>\n
 <\/p>\n
\n
\/\/ nodiscardString.cpp<\/span>\r\n\r\n#include <utility><\/span>\r\n\r\nstruct<\/span> MyType {\r\n\r\n     [[nodiscard(\"Implicit destroying of temporary MyInt.\"<\/span>)]] MyType(int<\/span>, bool<\/span>) {}\r\n\r\n};\r\n\r\ntemplate<\/span> <<\/span>typename<\/span> T, typename<\/span> ... Args><\/span>\r\n[[nodiscard(\"You have a memory leak.\"<\/span>)]]\r\nT*<\/span> create(Args&&<\/span> ... args){\r\n  return<\/span> new<\/span> T(std::<\/span>forward<<\/span>Args><\/span>(args)...);\r\n}\r\n\r\nenum<\/span> class <\/span>[[nodiscard(\"Don't ignore the error code.\"<\/span>)]] ErrorCode {\r\n    Okay,\r\n    Warning,\r\n    Critical,\r\n    Fatal\r\n};\r\n\r\nErrorCode errorProneFunction<\/span>() { return<\/span> ErrorCode::<\/span>Fatal; }\r\n\r\nint<\/span> main<\/span>() {\r\n\r\n    int<\/span>*<\/span> val =<\/span> create<<\/span>int<\/span>><\/span>(5<\/span>);\r\n    delete<\/span> val;\r\n\r\n    create<<\/span>int<\/span>><\/span>(5<\/span>);         \/\/ (1)<\/span>\r\n\r\n    errorProneFunction();   \/\/ (2)<\/span>\r\n    \r\n    MyType(5<\/span>, true<\/span>);        \/\/ (3)<\/span>\r\n\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
Now, the user of the functions gets a specific message. Here is the output of the Microsoft compiler.<\/p>\n
\"nodiscardString2\"<\/p>\n
By the way, many existing functions in C++ could benefit from the [[nodiscard]]<\/span> attribute. For example, when you don’t use the return value of std::asnyc,<\/span> an asynchronously meant std::async<\/span> call becomes implicitly synchronous. What should run in a separate thread behaves as a blocking function call. Read more about the counterintuitive behavior of std::async<\/span> in my blog “The Special Futures<\/a>“.<\/p>\n
While studying the [[nodiscard]]<\/span> syntax on cppreference.com<\/a>, I noticed that the overload of std::async<\/span> changed with C++20. Here is one:<\/p>\n
\n
template<\/span><<\/span> class<\/span> Function<\/span>, class... Args><\/span>\r\n[[nodiscard]]\r\nstd::<\/span>future<<\/span>std::<\/span>invoke_result_t<\/span><<\/span>std::<\/span>decay_t<\/span><<\/span>Function><\/span>,\r\n                                 std::<\/span>decay_t<\/span><<\/span>Args><\/span>...>><\/span>\r\n    async( Function&&<\/span> f, Args&&<\/span>... args );\r\n<\/pre>\n<\/div>\n
 <\/p>\n
std::future<\/span> as return-type of the promise std::async<\/span> is declared as [[nodiscard]]<\/span>.<\/p>\n
The following two attributes [[likely]]<\/span> and [[unlikely]]<\/span>, are about optimization.<\/p>\n<\/p>\n
[[likely]]<\/span> and [[unlikely]]<\/span><\/h3>\n
The proposal P0479R5 for likely and unlikely attributes is the shortest proposal I know of. To give you an idea, this is an interesting note to the proposal. “The use of the likely<\/strong><\/span> attribute is intended to allow implementations to optimize for the case where paths of execution including it are arbitrarily more likely than any alternative path of execution that does not include such an attribute on a statement or label. The use of the unlikely<\/strong><\/span> attribute is intended to allow implementations to optimize for the case where paths of execution including it are arbitrarily more unlikely than any alternative path of execution that does not include such an attribute on a statement or label. A path of execution includes a label if and only if it contains a jump to that label. Excessive usage of either of these attributes is liable to result in performance degradation<\/em>.”<\/p>\n
To make it short, both attributes allow it to give the optimizer a hint about which path of execution is more or less likely.<\/p>\n
\n
for<\/span>(size_t<\/span> i=<\/span>0<\/span>; i <<\/span> v.size(); ++<\/span>i){\r\n    if<\/span> (v[i] <<\/span> 0<\/span>) [[likely]] sum -=<\/span> sqrt(-<\/span>v[i]);\r\n    else<\/span> sum +=<\/span> sqrt(v[i]);\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
 The story with optimization goes on with the new attribute [[no_unique_address]<\/span>]. This time the optimization addresses space.<\/p>\n
[[no_unique_address]]<\/span><\/h3>\n
[[no_unique_address]]<\/span> expresses that this data member of a class need not have an address distinct from all other non-static data members of its class. Consequently, if the member has an empty type, the compiler can optimize it to occupy no memory.<\/span><\/p>\n
The following program exemplifies the usage of the new attribute.<\/p>\n
 <\/p>\n
\n
\/\/ uniqueAddress.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n \r\nstruct<\/span> Empty {}; \r\n \r\nstruct<\/span> NoUniqueAddress {\r\n    int<\/span> d{};\r\n    Empty e{};\r\n};\r\n \r\nstruct<\/span> UniqueAddress {\r\n    int<\/span> d{};\r\n    [[no_unique_address]] Empty e{};                                     \/\/ (1)<\/span>\r\n};\r\n \r\nint<\/span> main<\/span>() {\r\n\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>boolalpha;\r\n\r\n    std::<\/span>cout <<<\/span> \"sizeof(int) == sizeof(NoUniqueAddress): \"<\/span>              \/\/ (2)<\/span>\r\n              <<<\/span> (sizeof<\/span>(int<\/span>) ==<\/span> sizeof<\/span>(NoUniqueAddress)) <<<\/span> std::<\/span>endl;\r\n \r\n    std::<\/span>cout <<<\/span> \"sizeof(int) == sizeof(UniqueAddress): \"<\/span>                \/\/ (3)<\/span>\r\n              <<<\/span> (sizeof<\/span>(int<\/span>) ==<\/span> sizeof<\/span>(UniqueAddress)) <<<\/span> std::<\/span>endl;\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \r\n    NoUniqueAddress NoUnique;\r\n    \r\n    std::<\/span>cout <<<\/span> \"&NoUnique.d: \"<\/span> <<<\/span>  &<\/span>NoUnique.d <<<\/span> std::<\/span>endl;           \/\/ (4)<\/span>\r\n    std::<\/span>cout <<<\/span> \"&NoUnique.e: \"<\/span> <<<\/span>  &<\/span>NoUnique.e <<<\/span> std::<\/span>endl;           \/\/ (4)<\/span>\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \r\n    UniqueAddress unique;\r\n    \r\n    std::<\/span>cout <<<\/span> \"&unique.d: \"<\/span> <<<\/span>  &<\/span>unique.d <<<\/span> std::<\/span>endl;               \/\/ (5)<\/span>\r\n    std::<\/span>cout <<<\/span> \"&unique.e: \"<\/span> <<<\/span>  &<\/span>unique.e <<<\/span> std::<\/span>endl;               \/\/ (5)<\/span>\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The class NoUniqueAddress<\/span> has another size as an int<\/span> (2) but not the class UniqueAddress<\/span> (3). The members d<\/span> and e<\/span> of NoUniqueAddress<\/span> (4) have different addresses but not the members of the class UniqueAddress (5).<\/span><\/p>\n
 <\/div>\n
\"uniqueAddress\"<\/p>\n
What’s next?<\/h2>\n
The volatile<\/span> qualifier is one of the darkest corners in C++. Consequently, most of volatile<\/span> has been deprecated in C++20.<\/p>\n
 <\/div><\/p>\n","protected":false},"excerpt":{"rendered":"
With C++20, we got new and improved attributes such as [[nodiscard(“reason”)]], [[likely]], [[unlikely]], and [[no_unique_address]]. In particular, [[nodiscard(“reason”)]] allows it to express the intention of your interface way clearer.<\/p>\n","protected":false},"author":21,"featured_media":5945,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[375],"tags":[],"class_list":["post-5967","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-c-20"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5967","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=5967"}],"version-history":[{"count":0,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5967\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5945"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5967"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5967"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5967"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}