Copy Elision

[@MinhTran-wn1ri]

@4:57 *data_c* is default-constructed (parameterless constructor invoked) then Widget's *copy constructor* (not copy assignment) is called to _construct_ data_d. The copy assignment operator is invoked when you're assigning one initialized Widget to another, already initialized, Widget: Widget data_c; Widget data_d; data_c = data_d; // Copy assignment invoked to copy data_d Widget data_e; Widget data_f = data_e; // Same as Widget data_f{data_e}; which invokes copy constructor.

[@bwatspro]

Best Cpp tutorials on youtube

[@zsoltory4176]

Unnecessary copies, where heap storage is involved, like e. g. copying std::sets or std::maps, where new possibly small chunks of memory have to be allocated for the copy, where the original chunk copied from still remains on the heap, may lead to avoidable heap fragmentation. Heap fragmentation bloats the heap with unusable small chunk and thus decreasing the effectively usable heap. Thus moving data wherever possible may also prevent heap fragmentation. In addition, storage allocation on a fragmented heap is not only more effective but also faster.

[@CopperSpice]

Did you have a question about Copy Elision?

[@zsoltory4176]

@@CopperSpice No, I just made the remark above. The effect described there considerably improved heap consumption and speed of one of my programs.

[@Betheev]

AFAIK, copy assignment only takes place when the variable being assigned a value to had already been created in a previous step. If it is created in the same step, the copy constructor is called. I quicky tested the second example with std=C++11 -fno-elide-constructor and the assignment operator is not called

[@CopperSpice]

You mentioned "previous step" and "same step" which is a bit vague since there are no "steps" in C++ code. I am not sure if this refers to a statement, an expression, or a subexpression, which are all a bit different. One of the issues with testing compiler options is that optimization is difficult to observe. Running an experiment tells you how your compiler interprets the code, not how the standard defines it. The purpose of these examples is to illustrate that the compiler was allowed to elide prior to C++17, but this elision is guaranteed by the C++17 standard.

[@danwest9900]

These c++ videos are EXCELLENT! Thank you very much for posting!

[@CopperSpice]

Thanks so much for your comment. It's great to know when people find our videos useful. Please let everyone know about our channel!

[@danwest9900]

@@CopperSpice I will!

[@kormisha]

One if the first rules regarding this I learned that construction of a new object using the assignment is always by a copy constitution; the assignment operator is not involved. I do not think that is a compiler dependent.

[@kbsanders]

🎵 Copy Elision down the road that I must travel. Copy Elision through the darkness of the night. 🎵 🤣

[@stephanbokelmann507]

Awesome explanation! Thanks

[@josephlagrange9531]

I love your work!

[@A1Googler]

Thank you for posting.

[@gusromul3356]

hmm... slide at about 3m30s suggests data_d triggers operator=()?? shouldnt it be copy ctor?

[@gusromul3356]

oh, sorry, i should have read the other posts before posting the above (i see ppl have already pointed out the issue).. anyhow, great videos nevertheless

[@tomay3000]

Good to know, thanks. Do we expect to have garbage collectors like Java and C# for C++ in the future?

[@CopperSpice]

It turns out garbage collection is an optional feature in the standard. The problem is that GC is really complicated and has a performance impact. If you call std::get_pointer_safety() and the return value is "strict" then your C++ standard library *may* provide a garbage collector. From what we know, no current standard library provides it.

[@RoyalGun-9mm]

great work

[@hasanrasulov3502]

Thank you

[@Bob-zg2zf]

Lovely!