{"id":104367,"date":"2020-10-14T07:00:00","date_gmt":"2020-10-14T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=104367"},"modified":"2020-10-14T10:17:20","modified_gmt":"2020-10-14T17:17:20","slug":"20201014-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20201014-00\/?p=104367","title":{"rendered":"A brief introduction to C++ structured binding"},"content":{"rendered":"

C++17 introduced a feature known as structured binding<\/i><\/a>. It allows a single source object to be taken apart:<\/p>\n

std::pair<int, double> p{ 42, 0.0 };\r\nauto [i, d] = p;\r\n\/\/ int i = 42;\r\n\/\/ double d = 0.0;\r\n<\/pre>\n
It seems that no two languages agree on what to call this feature. C# calls it  deconstructing<\/i><\/a>. JavaScript calls it  destructuring<\/i><\/a>. (Python doesn’t seem to have a specific name for this concept, although the common case where the source is a list does have the name list comprehension<\/i>.)<\/span> Python calls it  unpacking<\/i><\/a>. My guess is that C++ avoided both of these terms to avoid confusion with the word destructor<\/i>.<\/p>\n
There is a subtlety in the way structured binding works: Binding qualifiers on the auto<\/code> apply to how the source<\/i> is bound, not on how the destination<\/i> is bound.\u00b9<\/p>\n
For example,<\/p>\n
auto&& [i, d] = p;\r\n<\/pre>\n
becomes (approximately)\u00b9<\/p>\n\n\n\n\n
If p.get<N><\/tt> exists<\/th>\nIf p.get<N><\/tt> does not exist<\/th>\n<\/tr>\n
auto&&<\/u> hidden = p;<\/tt>
\ndecltype(auto) i = p.get<0>();<\/tt>
\ndecltype(auto) d = p.get<1>();<\/tt><\/td>\n		auto&&<\/u> hidden = p;<\/tt>
\ndecltype(auto) i = get<0>(p);<\/tt>
\ndecltype(auto) d = get<1>(p);<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
where hidden<\/code> is a hidden variable introduced by the compiler. The declarations of i<\/code> and d<\/code> are inferred from the get<\/code> method or free function.\u00b2<\/p>\n
(In a cruel twist of fate, if hidden<\/code> is const or a const reference, then that const-ness propagates to the destinations. But the reference-ness of hidden<\/code> does not propagate.)<\/p>\n
The decltype(auto)<\/code> means that the reference-ness of the return type is preserved rather than decayed. If get<\/code> returns a reference, that reference or qualifier is preserved. This differs from auto<\/code> which will decay references to copies.<\/p>\n
All of this comes into play when you want to make your own objects available to structured binding, which we’ll look at next time.<\/p>\n
Bonus chatter<\/b>: There is no way to specify that you want only selected pieces. You must bind all the pieces.<\/p>\n
\u00b9 In reality, the bound variables have underlying type std::tuple_element_t<N, T><\/code> (where N<\/code> is the zero-based index and T<\/code> is the type of the source), possibly with references added. But in practice, these types match the return types of get<\/code>, so it’s easier just to say that they come from get<\/code>.<\/p>\n
\u00b2 My reading of the language specification is that the destination variables are always references:<\/p>\n
[dcl.struct.bind]<\/b>
\n3. \u2026 [E]ach v<\/tt>\u1d62 is a variable of type \u201creference to T<\/tt>\u1d62\u201d initialized with the initializer, where the reference is an lvalue reference if the initializer is an lvalue and an rvalue reference otherwise.<\/p><\/blockquote>\n
and therefore the expansion of the structured binding would be<\/p>\n
auto&&<\/u> i = get<0>(p);\r\nauto&&<\/u> d = get<1>(p);\r\n<\/pre>\n
However, in practice, the compilers declare the destination variables as matching the return value of get<\/code>, as I noted above.<\/p>\n
So I must be reading the specification wrong.<\/p>\n
(The text was  revised for C++20<\/a>, but even in the revision, it’s still a reference.)<\/p>\n
\u00b9 That’s because a structured binding really<\/i> is a hidden variable plus a bunch of references to the pieces of that hidden variable. That’s why the qualifiers apply to the hidden variable, not to the aliases.<\/p>\n","protected":false},"excerpt":{"rendered":"
Just learning the basics.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-104367","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Just learning the basics.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104367","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=104367"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104367\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=104367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=104367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=104367"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}