{"id":5655,"date":"2019-03-20T06:35:03","date_gmt":"2019-03-20T06:35:03","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/c-insights-type-deduction\/"},"modified":"2023-06-26T10:13:04","modified_gmt":"2023-06-26T10:13:04","slug":"c-insights-type-deduction","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c-insights-type-deduction\/","title":{"rendered":"C++ Insights – Type Deduction"},"content":{"rendered":"

Andreas Fertigs story with C++ Insights goes on. This weeks post is about type deduction with auto<\/code> and decltype <\/code>or as I often phrase it: “Use the smartness of the compiler.”<\/p>\n

<\/p>\n

\"02<\/h2>\n

Type Deduction<\/h2>\n

 <\/p>\n

With C++11 we got auto<\/code> and decltype<\/code> and, therefore, two new forms of type deduction. We are used to type deduction from templates, however, these two new variants can be tricky sometimes.<\/p>\n

auto<\/span><\/h3>\n

 <\/p>\n

Consider this example:<\/p>\n

\n
int<\/span> main<\/span>()\r\n{\r\n  int<\/span>*<\/span> ip;\r\n  const<\/span> int<\/span>*<\/span> cip;\r\n  const<\/span> int<\/span>*<\/span> const<\/span> cicp =<\/span> ip;\r\n\r\n  auto<\/span> aip =<\/span> ip;\r\n  auto<\/span> acip =<\/span> cip;\r\n  auto<\/span> acicp =<\/span> cicp;\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
We have three different pointers, all of type int<\/code>. They are getting more and more constified. The question is what\u2019s the type that is deduced by auto<\/code>? All are pointers, that\u2019s for sure. But what happens with the const<\/code>? auto<\/code> removes all top-level qualifier. Hence, even the const<\/code> disappears. Does it? Here is the output C++ Insights gives:<\/p>\n
 <\/p>\n
int<\/span> main<\/span>()<\/span>
<\/span>{<\/span>
  int<\/span> * ip;<\/span>
  const<\/span> int<\/span> * cip;<\/span>
  const<\/span> int<\/span> *const<\/span> cicp = ip;<\/span>
  int<\/span> * aip = ip;<\/span>
  const<\/span> int<\/span> * acip = cip;<\/span>
  const<\/span> int<\/span> * acicp = cicp;<\/span>
}<\/span>
<\/code><\/pre>\n
 <\/p>\n
Yes, the top-level const<\/code> is removed. A constant pointer does not matter, so this const<\/code> is discarded, but the constness of the memory behind it sticks. Hence, this const<\/code> is preserved. Which is why acip<\/code> looks exactly like acicp<\/code>. This makes sense right.<\/p>\n
decltype(auto)<\/span><\/h3>\n
Now, from time to time we like to preserve all qualifiers. This is when decltype<\/code> appears. In contrast to auto<\/code>, decltype<\/code> does preserve all top-level qualifiers. With  C++14 the combination of decltype<\/code> and auto<\/code> is possible and we can write decltype(auto)<\/code> which makes things easier. Here is another example from C++<\/ins> Insights which uses C++14:<\/p>\n
 <\/p>\n
\n
int<\/span> main<\/span>()\r\n{\r\n  int<\/span>*<\/span> ip;\r\n  const<\/span> int<\/span>*<\/span> cip;\r\n  const<\/span> int<\/span>*<\/span> const<\/span> cicp =<\/span> ip;\r\n\r\n \r\n\r\n  decltype(auto<\/span>) aip =<\/span> ip;\r\n  decltype(auto<\/span>) acip =<\/span> cip;\r\n  decltype(auto<\/span>) acicp =<\/span> cicp;\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
From this we get the following output:<\/p>\n
 <\/p>\n
int<\/span> main<\/span>()<\/span>
<\/span>{<\/span>
  int<\/span> * ip;<\/span>
  const<\/span> int<\/span> * cip;<\/span>
  const<\/span> int<\/span> *const<\/span> cicp = ip;<\/span>
  int<\/span> * aip = ip;<\/span>
  const<\/span> int<\/span> * acip = cip;<\/span>
  const<\/span> int<\/span> *const<\/span> acicp = cicp;<\/span>
}<\/span>
<\/code><\/pre>\n
 <\/p>\n
We can see, that acicp<\/code> does carry the second const<\/code> which is lost when we just use auto<\/code><\/span>.<\/p>\n<\/p>\n
decltype<\/span><\/h3>\n
When do we need decltype<\/code>, or more precisely when do we like to keep all qualifiers? One popular reason is templates. Imagine a class template with some function Get. With just using auto<\/code> it as a return type we can never return a reference to something. In template code, we often don\u2019t know the exact types, which makes it desirable to provide code that just works. decltype<\/code> can help here. However, consider decltype<\/code> a library writer feature. In most cases, we are fine with auto<\/code>. It is just good to know the entire toolbox.<\/p>\n
auto& and auto* versus auto<\/span><\/h3>\n
What we\u2018ve seen so far is, that we need to be explicit, if it comes to auto<\/code> and references. We must always write auto&<\/code> to get a reference. How is it with pointers? There auto<\/code> gives us the correct type, so we can spare the star? This is in fact a question I frequently get from my students. The answer is: it depends. I recommend writing it just for consistency. However, there are scenarios where we indeed need auto* even that auto<\/code> did deduce the correct type. Consider this example<\/a>:<\/p>\n
\n
struct<\/span> Foo{};\r\n\r\nFoo*<\/span> GetFoo<\/span>()\r\n{\r\n   static<\/span> Foo foo;\r\n\r\n   return<\/span> &<\/span>foo;\r\n}\r\n\r\nint<\/span> main<\/span>()\r\n{\r\n  auto<\/span> fp =<\/span> GetFoo();\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
We have a function returning a Foo*<\/code> and an auto<\/code> variable auto f = GetFoo()<\/code> which deduces the type. Of course, the correct type. What if we\u2019d like to make f<\/code> const? That we cannot alter the data of f<\/code>? Sure, we write it like this const auto f = ...<\/code>. At least that\u2019s what we would do if we write it without auto<\/code>. Here are some possibilities we can try:<\/p>\n
\n
struct<\/span> Foo{};\r\n\r\nFoo*<\/span> GetFoo<\/span>()\r\n{\r\n   static<\/span> Foo foo;\r\n\r\n   return<\/span> &<\/span>foo;\r\n}\r\n\r\nint<\/span> main<\/span>()\r\n{\r\n   auto<\/span> fp0 =<\/span> GetFoo();\r\n   const<\/span> auto<\/span> fp1 =<\/span> GetFoo();\r\n   auto<\/span> const<\/span> fp2 =<\/span> GetFoo();\r\n   \/\/const auto const fp3 = GetFoo(); does not compile<\/span>\r\n   const<\/span> auto<\/span>*<\/span> fp4 =<\/span> GetFoo();\r\n   auto<\/span>*<\/span> const<\/span> fp5 =<\/span> GetFoo();\r\n   const<\/span> auto<\/span>*<\/span> const<\/span> fp6 =<\/span> GetFoo();\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
First, fp1<\/code> produces a const pointer to mutable data. Not exactly what we intended. fp2<\/code> probably seems pointless. fp3<\/code> makes more sense, but this doesn\u2019t compile. The control changes, if we start using the form auto*<\/code>. Now, we can add the qualifiers like we can do it with a regular type. But see<\/a> for yourself in C++ Insights what the result is:<\/p>\n
 <\/p>\n
struct Foo{\/* public: inline constexpr Foo() noexcept; *\/<\/span>
\/* public: inline constexpr Foo(const Foo &); *\/<\/span>
\/* public: inline constexpr Foo(Foo &&); *\/<\/span>
};<\/span><\/pre>\n
Foo * GetFoo()<\/span>
{<\/span>
   static Foo foo = Foo();<\/span>
   return &foo;<\/span>
}<\/span><\/p>\n
int main()<\/span>
{<\/span>
   Foo * fp0 = GetFoo();<\/span>
   Foo *const fp1 = GetFoo();<\/span>
   Foo *const fp2 = GetFoo();<\/span>
   const Foo * fp4 = GetFoo();<\/span>
   Foo *const fp5 = GetFoo();<\/span>
   const Foo *const fp6 = GetFoo();<\/span>
}<\/span>
<\/code><\/p>\n
 <\/p>\n
The simple advice is: always be explicit and use the form auto&<\/code> as well as auto*<\/code> even if auto is able to deduce a pointer type.<\/p>\n
 <\/p>\n
Let\u2019s say we are explicit and use auto&<\/code>. Look at this example<\/a>:<\/p>\n
\n
struct<\/span> Singleton{};\r\n\r\nauto<\/span> Get<\/span>()\r\n{\r\n   static<\/span> Singleton s{};\r\n\r\n   return<\/span> s;\r\n}\r\n\r\nint<\/span> main<\/span>()\r\n{\r\n   auto<\/span>&<\/span> x =<\/span> Get();\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
We have a classical singleton which the function Get<\/code> should return. Of course, we like a reference to it otherwise we have multiple tons. Despite auto<\/code> and &<\/code> this code does not compile:<\/p>\n
error: non-const lvalue reference to type 'Singleton' cannot bind to a temporary of type 'Singleton'
<\/code><\/pre>\n
The reason is, the Get<\/code> in fact return Singleton<\/code> and not Singleton&<\/code>. Why? Because we did not apply the &<\/code> to the auto-return type of Get<\/code>. A small change and the code compiles:<\/p>\n
\n
struct<\/span> Singleton{};\r\n\r\nauto<\/span>&<\/span> Get()\r\n{\r\n   static<\/span> Singleton s{};\r\n\r\n   return<\/span> s;\r\n}\r\n\r\nint<\/span> main()\r\n{\r\n   auto<\/span>&<\/span> x =<\/span> Get();\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
I\u2019d like to thank Rainer for the opportunity to share information about C++ Insights on his popular blog!<\/p>\n
Have fun with C++ Insights. You can support the project by becoming a Patreon<\/a> or of course with code contributions<\/a>.<\/p>\n
Stay tuned for more insights about C++ Insights to template instantiation \u2026<\/p>\n
 <\/p>\n
Andreas<\/strong><\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Andreas Fertigs story with C++ Insights goes on. This weeks post is about type deduction with auto and decltype or as I often phrase it: “Use the smartness of the compiler.”<\/p>\n","protected":false},"author":21,"featured_media":5654,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[374],"tags":[436,437],"class_list":["post-5655","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cppinsight","tag-auto","tag-decltype"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5655","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=5655"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5655\/revisions"}],"predecessor-version":[{"id":6793,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5655\/revisions\/6793"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5654"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5655"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5655"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5655"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}