This reminds me of tail recursion in functional languages: a function calling itself recursively as its *last* action can have its context safely removed from the stack, and replaced by the context of the callee.
the thing I like the most most about C++ is how simple and straight forward it is, no gotchas or special cases, what you see is what you get, it's amazing really
LOL, what a load of crap -- it is literally the exact opposite -- did you not see the copy constructor that was marked as deleted and how it behaves differently in 11 and 17 ?
I understood practically nothing about copy elision from a lot of resources until I came across this video, and in ten minutes I was able to understand it fully. Thank you!
The world would be a better place if C++'s constructor rules didn't make my stomach twist in anxiety. Non-default constructors invite the devil into your home, and you'd never rest easy knowing you may have accidentally missed a common gotcha and now there's 5 heap allocated std::strings under your bed.
this was an awesome video -- i learned C++ WAY BACK before the "modern age" and i really hated it but these required optimizations make it sound much better than i remember
Thanks for the great videos James, you're the best programming channel on RU-vid. Always interesting and useful content explained clearly with no filler.
Sean Parent in one of his brilliant talks went through this kind of copy behavior (but in code that actually doesn't allow compiler to do it magic, being a code smell). Fascinating stuff.
"Haven't said anything about move ops, but listing out more cases doesn't do anything good" - well, actually, every single one of your examples were calling MOVE, and not COPY constructor just your example S class' move constructor is the copy constructor (because you didn't implement a move, move is using the copy ctr).
I'm not sure what exactly your objection is here (perhaps you could elaborate?). Yes, the compiler will move returned local variables if a move constructor is available. No move was provided so it called the user-defined copy constructor. Are you saying I should still refer to this as a move even though the copy constructor was called and no move constructor is provided or generated by the compiler? I'm not sure I would agree with calling it a move in that situation, especially not colloquially. Colloquially, when one speaks of eliminating copies and eliminating moves, one is typically referring the act of reducing the number of times the copy constructor or move constructor actually gets called, i.e. an empirical reduction in copies or moves, not a reduction in places where the standard would allow a copy/move. In any case, it is not correct to say that the move constructor "is the copy constructor" if one is not provided. The definition of copy/move constructor in the standard is based on the signature of the function alone. It is *not* based on whether it is called when initializing from a prvalue. Instead, the compiler may chose to copy *instead of* move due to the fact that no move constructor is available.
Nice video. I was a bit stumped on 7:06 thinking it should be possible to move the value given both s1 and s2 are ephemeral values local to the function but then I remembered this is a compiler optimization, not a runtime optimization. So then I wondered if a simple design change to the code would work around such a case by doing the branching before calling the function. It's a interesting consideration that I wouldn't have thought to do before this, but it has performance implications.
I think I just experienced a bug at work in C# that was due to this copy elision. I was doing something other than copying in the copy constructor, and it wasn't being done! Thanks for opening my eyes!
It'd be nice if that rule were more clearly and concretely defined. Ideally it should always optimize it away, and in the case of the two values caught by control flow, while it couldn't always catch that, I hope modules mitigate some of the cases where it wouldn't. Obviously when taking user input to decide that control flow it will never optimize it away, but with a constant as in the example I hope it does.
afaik, the compiler can’t do that - if a function is called ( explicitly ), it must be called. That optimization would mean you would be calling a different function.
@@mCoding In my case, I've ditched C++ after learning about Rust, at least for me, Rust is just C++ minus the enormous headaches that came with the language. I was using C++ for only 2-3 months or so, it's kinda funny how I switched languages so quickly.
@@Tibor0991 LOL. I've spent more than a decade with C++, I just got tired of dealing with the pointless obstacles that it puts in the developer's way for no good reason. You've got an "object oriented language" with a "standard library", but you can't use actual objects or types from the standard library in the public interface of your library unless the user happens to use the same compiler? Get outta here.
6:55 couldn't you arbitrarily choose one of either s1 or s2 to be constructed in the return value space, and then in the worst case if it ends up being the other one, you have to copy and overwrite it (shouldn't make performance worse if I'm not missing something) and in the best case you guessed correctly and you can elide the copy. The compiler could even try to figure out which branch is more likely and choose which variable to construct in the return value space based on that. I'm guessing that this optimisation isn't mentioned in the language standard, but would a compiler still be allowed to do it, at least if the elided copy constructor has no side effects?
A great one to test on compiler explorer! godbolt.org/z/rYq1ejzKW Even in C++23 at -O3 with "if (true)" we still see the copy. Note however that if you move the instantiations of s1, s2 inside the scope of the if block that they are actually returned in, then the copy can be elided because they will no longer interfere with each other.
I'm not that great at c++.If someone can help me, one of the problems I face often is the hash for a few template types just aren't defined. For example if I want to put a pair of ints or a tuple of ints in an unordered_map as keys, I can't do it. Any easy ways to get around this?
Honestly, what he showed is quite irrelevant to how you code in Cpp. Why? Because you would never do what he did here. I can not think of any context this knowledge would be useful.
@@Kurkkulimu I think he means because you don't have to jump through hoops to avoid unnecessary copying as well as to make the compiler generate optimized code.
