{"id":1027,"date":"2019-10-23T21:15:42","date_gmt":"2019-10-24T02:15:42","guid":{"rendered":"http:\/\/sunapi386.ca\/wordpress\/?p=1027"},"modified":"2019-10-23T21:15:50","modified_gmt":"2019-10-24T02:15:50","slug":"c-what-is-copy_elision-and-why-you-should-know-about-it","status":"publish","type":"post","link":"https:\/\/sunapi386.ca\/wordpress\/c-what-is-copy_elision-and-why-you-should-know-about-it\/","title":{"rendered":"[C++] What is copy_elision and why you should know about it"},"content":{"rendered":"\n

In the C++ world, copy_elision<\/strong> is a compiler optimization. <\/p>\n\n\n\n

Prior to C++11, there was no copy_elision, so when you write code like this…<\/p>\n\n\n\n

Person makePerson() {\n    Person p();\n    p.name = \"Bob\";\n    return p;\n}<\/code><\/pre>\n\n\n\n
… the compiler creates a Person object in the makePerson stack frame and is copied\/moved to the caller’s stack after makePerson finshes.<\/p>\n\n\n\n
But with with copy_elision, the compiler optimizes the process and rather than a move\/copy, compiler sets the address of makePerson’s Person directly to the return address. In other words, there is no move\/copy. <\/p>\n\n\n\n
Explained by the official website https:\/\/en.cppreference.com\/w\/cpp\/language\/copy_elision<\/a><\/p>\n\n\n\n
The objects are constructed directly into the storage where they would otherwise be copied\/moved to.<\/p><\/blockquote>\n\n\n\n
This optimization is usually unnoticed.<\/p>\n\n\n\n
Great! So what? Why do I need to care about this?<\/h2>\n\n\n\n
Tl;dr: When you lie to the compiler. <\/p>\n\n\n\n
As a general rule: if you lie to the compiler, there lies bugs, undefined behavior, and probably stack smashing.<\/p>\n\n\n\n
Let me tell a story about using ROS<\/a>. <\/h2>\n\n\n\n
ROS creates a layer of abstraction for inter process communication (IPC) with sockets, in a publisher\/subscriber model.<\/p>\n\n\n\n
The ROS semantics for a subscriber is very overloaded, as in there are many definitions of “subscribe”.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
http:\/\/docs.ros.org\/lunar\/api\/roscpp\/html\/classros_1_1NodeHandle.html<\/a><\/p>\n\n\n\n
Here’s what happened.<\/p>\n\n\n\n
I defined an Object and created a callback. E.g. Cards object and callback_add_card(Card newCard). <\/p>\n\n\n\n
Important<\/strong>: The callback returned an int. E.g. “int callback_add_card”.<\/strong>
This leads me to make a mistake… We shall see why later.<\/strong><\/p>\n\n\n\n
I constructed the object and passed that object’s callback to ROS subscribe. <\/p>\n\n\n\n
But ROS’s subscribe definition expected (void*) function pointer. 
I.e. void callback_add_card was acceptable but int callback_add_card is not. <\/strong>
So I lied to the compiler and cast this to a void*. Subtle mistake. Won’t show up until later.<\/p>\n\n\n\n
#define callback_add_card_fn (void <\/strong>(Cards::*)(const <\/strong>Card&))\n\nnodeHandle.subscribe(\"\/cards\/add\", subscribeQueueSize, callback_add_card_fn &Cards::callback_add_card, &my_cards);<\/pre>\n\n\n\n
The compiler was happy and compiled. Because the “#define cb_car_speed …” told the compiler to treat the function as void.<\/p>\n\n\n\n
Code mostly worked fine.<\/strong><\/p>\n\n\n\n
Because an int is relatively small (byte), there appears to be no bugs because the stack smashing wasn’t obvious.<\/p>\n\n\n\n
Sometime later, I changed the return type.
From int callback_add_card to Card callback_add_card.
Because why not just return the Card instead? So I can write some test code and see if the Card is correct.<\/p>\n\n\n\n
Well! Now we have big trouble.<\/p>\n\n\n\n
The compiler was told this callback_add_card had void return type. So compiler did not allocate any space for a return value. And because of copy_elison, the compiler had generated code for callback_add_card “directly into the storage where they would otherwise be copied\/moved to.<\/em>” <\/p>\n\n\n\n
In other words, calling <\/strong>callback_add_card smashes the stack of the caller. Because the caller expected void  return value, and no spaces was allocated. <\/strong>But the copy_elison code constructed the Card object in the caller’s stack frame!<\/strong><\/span><\/p>\n\n\n\n
So how do we get around this? How to have a callback that returns some value, but still call the ROS subscribe properly?<\/h2>\n\n\n\n
Answer: By wrapping the call in a lambda, creating a closure. The lambda returns no value, so it’s a void function. But the lambda can capture context. E.g.<\/p>\n\n\n\n
nodeHandle.subscribe<Card>(\"\/cards\/add\", subscribeQueueSize, [&my_cards](Card newCard) {\n  cout << \"the card added is: \" << my_cards.callback_add_card() << \"\\n\";\n});<\/pre>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
In the C++ world, copy_elision is a compiler optimization. Prior to C++11, there was no copy_elision, so when you write code like this… … the compiler creates a Person object in the makePerson stack frame and is copied\/moved to the caller’s stack after makePerson finshes. But with with copy_elision, the compiler optimizes the process and … Continue reading [C++] What is copy_elision and why you should know about it<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[34],"tags":[],"class_list":["post-1027","post","type-post","status-publish","format-standard","hentry","category-thoughts"],"_links":{"self":[{"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/posts\/1027","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/comments?post=1027"}],"version-history":[{"count":1,"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/posts\/1027\/revisions"}],"predecessor-version":[{"id":1029,"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/posts\/1027\/revisions\/1029"}],"wp:attachment":[{"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/media?parent=1027"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/categories?post=1027"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sunapi386.ca\/wordpress\/wp-json\/wp\/v2\/tags?post=1027"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}