Yes, after so many references this is the first material which gave me a clear idea what is actually happening. Like more videos from the C++ committee.
Thank you for the talk! I am learning C++ as a novice and really enjoying these sessions! Very clear, with specific examples to explain the context and the value of the concept. 5/5!
I wore the spine out of his 1st edition of "The C++ Standard Library". Thanks so much for that book, it very much helped me learn how to use the C++ standard library!
Thank you so much for these amazing videos. I've borrowed Nicolai's book "The c++ Standard Library", You are so inspirational and give great examples, thank you Nicolai.
18:20 on "what is the state of the moved-from object, what can be done with it" it would be more useful to say _which methods get called_ after marking an object to be moved. Firstly, move turns all calls to construction and assignment from copy to move versions. So, the move constructor and the move assignment get called whenever construction and assignment are done in the code. It does not trigger any other methods on top of those two. Hence, the moved-from object is in whatever state that was left by the two standard move methods, constructor and assignment. Then, it's clear how the same works with functions and methods that take an && rvalue. Move returns an rvalue of the object, which tells the rest of the code that it can do whatever it wants with the rvalue object, its content is not needed. E.g. foo(string&& str) can clear the string or modify it or leave as is, i.e. leave it in valid but unknown for the caller state.
55:45 , 57:00 In C++ 20 you will use this a lot. Is there an actual compelling example? I haven’t seen much that using `auto&& c = thing()` Buys you over using `auto c = thing()` and then moving later instead of forwarding. One less move constructor call, and if it’s a copy only type will be one less copy, which is obviously good, however the trade off is much messier syntax. I would personally prefer the simpler, easier to read version with an extra possible copy and optimize later if it’s a performance bottle neck. But maybe I’m missing something?
53:26 I think "Jil" from the variable first will not be moved as the constructor of Cust takes const std::string& as parameter Good video. Give me motivation to see whats on C++20.
29:15 on not returning const value from a function - wasn't there a recommendation from Scott Meyers to return const value, to prevent the user from making calls on a temporary value by mistake? Maybe that was before the rvalues though!
11:52, instead of using `std::move()`, I think it's better to use `std::exchange()`, like: history.push_back(std::exchange(s, getDefaultValue())); That isn't only one-line implementation of `reinit()`, it is also efficient, as `std::exchange` moves the first parameter as well.
At 53:24 why would calling std::move(first) result in a _move_? The constructor has a const std::string& for the first parameter. So shouldn't it be a copy?
One point, on Page 22, string move semantics, string move constructor, dose s.data assigns to nullptr? I did some tests, data still is valid address. Pls correct me if I am wrong.
Question: It's not so nice having this T&& or auto&& for a universal reference since the type is vague. Would it be possible to confine the type with concepts / requires T is MyClass somehow? Also is there any plan to 'fix' forwarding in C++23?
Sure, it's easy using concepts: template concept ref_to = std::same_as; Then use it like: void f(ref_to auto&& p) { /*...*/ } This takes lvalue references and rvalue references, but only to MyClass.
"some" views not supporting iteration while const is a very nasty behaviour. More so since it is non-deterministic (at least at glance). Couldn't it be solved with mutable keyword? Recommending using auto&& so stuff works doesn't seem like the best idea as it is the first step to sacrifice const correctness.. :( Otherwise - great talk! The more I delve into the move semantics the more they seem unfinished. The "valid but unspecified state" effectively means that unless your compiler supports use-after-move detection then you shouldn't ever move a named variable or else you risk shooting yourself in the foot. If that detection was default, then the compiler would move a lot of stuff automatically. This way, you're forced to optimize by hand a risk a bug.
21:15 This is wrong. T&& where T is a template type isn’t a rvalue reference. Outside the context of a templates type this would be true, but, this accepts both r and l values.
You are ambiguous in crucial points, Nicolai. 11:30 you talk on this so much but you never explained what does _here_ mean. You repeat the word "move", that it doesn't _move_ anything, that it is a mark, etcetc, but you do not refer to the thing that matters: the _ownership_
A thoroughly excellent talk, this is by far the clearest and least confused explanation of C++ move semantics I have encountered. Bravo!
Yes, after so many references this is the first material which gave me a clear idea what is actually happening. Like more videos from the C++ committee.
wow. After struggling to understand move semantics for months...I finally get it. Thank you CPPCON & Nicolai Josuttis!!
看到一半，忍不住要给老师点个赞，讲得非常好！把move语意的引入原因，使用方法讲得透透的，谢谢
Quite a complete summary that exposes most if not all the move semantic intricacies.
Thank you for the talk! I am learning C++ as a novice and really enjoying these sessions!
Very clear, with specific examples to explain the context and the value of the concept. 5/5!
I wore the spine out of his 1st edition of "The C++ Standard Library". Thanks so much for that book, it very much helped me learn how to use the C++ standard library!
Thank you so much for these amazing videos. I've borrowed Nicolai's book "The c++ Standard Library", You are so inspirational and give great examples, thank you Nicolai.
Thank you for explaining why std::forward exists, it makes it easy to understand what it does and when you have to use it.
Very clear, concise and meticulous talk, much appreciated.
The best talk ever on this topic.
Thank you for making these videos, Mr Josuttis.
Brilliantly explained. Thank you Mr Josuttis.
Thankyou so much !!!
Finally i can understand the difference between push_back and emplace_back
This is a perfect explanation what the move semantics is.
Great example! Thanks to this video, now I have better understanding on move semantics.
Excellent!
Thank you so much for deeply understanding of the move semantic and universal forwarding.
18:20 on "what is the state of the moved-from object, what can be done with it" it would be more useful to say _which methods get called_ after marking an object to be moved. Firstly, move turns all calls to construction and assignment from copy to move versions. So, the move constructor and the move assignment get called whenever construction and assignment are done in the code. It does not trigger any other methods on top of those two. Hence, the moved-from object is in whatever state that was left by the two standard move methods, constructor and assignment.
Then, it's clear how the same works with functions and methods that take an && rvalue. Move returns an rvalue of the object, which tells the rest of the code that it can do whatever it wants with the rvalue object, its content is not needed. E.g. foo(string&& str) can clear the string or modify it or leave as is, i.e. leave it in valid but unknown for the caller state.
55:45 , 57:00
In C++ 20 you will use this a lot.
Is there an actual compelling example?
I haven’t seen much that using `auto&& c = thing()`
Buys you over using `auto c = thing()` and then moving later instead of forwarding.
One less move constructor call, and if it’s a copy only type will be one less copy, which is obviously good, however the trade off is much messier syntax.
I would personally prefer the simpler, easier to read version with an extra possible copy and optimize later if it’s a performance bottle neck.
But maybe I’m missing something?
53:26 I think "Jil" from the variable first will not be moved as the constructor of Cust takes const std::string& as parameter
Good video. Give me motivation to see whats on C++20.
@@squarerootof2 @talluay3567 is right. Cust constructor is called in the emplace_back() by calling the placement new operator
Thank you for the nice talk! "Back to Basics" to the bone.
Why do destructors in derived classes destroy move semantics?
The last part about universal reference was very useful.
Excellent presentation ! 👏
29:15 on not returning const value from a function - wasn't there a recommendation from Scott Meyers to return const value, to prevent the user from making calls on a temporary value by mistake? Maybe that was before the rvalues though!
Thank you Nicolai for such informative and detailed explanation of move semantics.
It would be interesting to read your ne books as well. ;)
Excellent, clear talk and the best on the subject. thank you!
Glad you enjoyed it!
best explanation on move semantics
the best move semantics out there.
11:52, instead of using `std::move()`, I think it's better to use `std::exchange()`, like:
history.push_back(std::exchange(s, getDefaultValue()));
That isn't only one-line implementation of `reinit()`, it is also efficient, as `std::exchange` moves the first parameter as well.
Excellent talk
Awesome 👏 ❤Thank you so much for sharing ❤
Thank you for this talk.
Well explained! Thx a lot!
good one, got the basics thanks
Really informative
very nicely explained, thanks.
You are welcome!
great talk as always
Thank you very much for your comment.
At 53:24 why would calling std::move(first) result in a _move_? The constructor has a const std::string& for the first parameter. So shouldn't it be a copy?
Dear @CppCon, I would love to get the slide deck of this talk. Is sharing it a possibility?
38:14 "it's completely on the stack" .... that's not true. It is in an already allocated memory (be it on the stack or heap).
One point, on Page 22, string move semantics, string move constructor, dose s.data assigns to nullptr? I did some tests, data still is valid address. Pls correct me if I am wrong.
Brilliant explanation.
Doesn't the c++ compiler elide the destructor at 7:12? It seems as though it should.
At 47:00 can anyone explain why foo(std::move(x)); will call the wrong function?
Question:
It's not so nice having this T&& or auto&& for a universal reference since the type is vague.
Would it be possible to confine the type with concepts / requires T is MyClass somehow?
Also is there any plan to 'fix' forwarding in C++23?
Sure, it's easy using concepts:
template
concept ref_to = std::same_as;
Then use it like:
void f(ref_to auto&& p) { /*...*/ }
This takes lvalue references and rvalue references, but only to MyClass.
@@FruchteisMitErdbeer It doesn't really look easy to read though
Great Talk!!!!!
just amazing
Nice 👌
Damn ... so much behind the scenes
my life would be better if i knew less c++
🖖
how to get slide？
Sorry, the slides are presently unavailable. We are looking to rectify this in the future.
"some" views not supporting iteration while const is a very nasty behaviour. More so since it is non-deterministic (at least at glance). Couldn't it be solved with mutable keyword? Recommending using auto&& so stuff works doesn't seem like the best idea as it is the first step to sacrifice const correctness.. :(
Otherwise - great talk! The more I delve into the move semantics the more they seem unfinished. The "valid but unspecified state" effectively means that unless your compiler supports use-after-move detection then you shouldn't ever move a named variable or else you risk shooting yourself in the foot. If that detection was default, then the compiler would move a lot of stuff automatically. This way, you're forced to optimize by hand a risk a bug.
21:15
This is wrong.
T&& where T is a template type isn’t a rvalue reference.
Outside the context of a templates type this would be true, but, this accepts both r and l values.
Would it not only be a universal reference, if the template was defined for the function only, not the complete class?
You are ambiguous in crucial points, Nicolai. 11:30 you talk on this so much but you never explained what does _here_ mean. You repeat the word "move", that it doesn't _move_ anything, that it is a mark, etcetc, but you do not refer to the thing that matters: the _ownership_