Back to Basics: C++ Move Semantics - Andreas Fertig - CppCon 2022
Vložit
- čas přidán 31. 10. 2022
- cppcon.org/
---
Back to Basics: C++ Move Semantics - Andreas Fertig - CppCon 2022
github.com/CppCon/CppCon2022
Move semantics is a topic that feels hard to understand. This talk will give you a good understanding, demystifying some myths out there using a new and unique way of talking about moving.
For example, you've heard those move operations should be noexcept. In this talk, you will learn the why while we write things like an efficient move constructor and a move assignment operator.
During this talk, we will look at rules for when to use std::move and when to use std::forward.
There is one topic we have to discuss as well, what is a moved-from object, and what can you do with such an object?
You're eager to squeeze out the last drop of performance? Then we should talk about the ref-qualifiers. Why waste performance?
At the end of this talk, you have a solid understanding of move semantics, enabling you to write competitive performant code.
---
Andreas Fertig
Andreas Fertig, CEO of Unique Code GmbH, is an experienced trainer and lecturer for C++ for standards 11 to 20.
Andreas is involved in the C++ standardization committee, in which the new standards are developed. At international conferences, he presents how code can be written better. He publishes specialist articles, e.g., for iX magazine, and has published several textbooks on C++.
With C++ Insights (cppinsights.io), Andreas has created an internationally recognized tool that enables users to look behind the scenes of C++ and thus to understand constructs even better.
Before working as a trainer and consultant, he worked for Philips Medizin Systeme GmbH for ten years as a C++ software developer and architect focusing on embedded systems.
You can find Andreas online at
andreasfertig.com
__
Videos Streamed, Edited, and CZcams Channel Managed by Digital Medium: online.digital-medium.co.uk
#cppcon #programming #cpp - Věda a technologie
This back to basics series is fantastic. For a novice programmer, these are invaluable
Excellent talk! Covers a lot of depth without too much jargon/overcomplication
Typo in slide 18. The first bullet should say `src` and not `other`.
"After applying `std::move`, `src` becomes a moved-from object"
Really great talk. Love the knowledge on forwarding and ref qualifiers! Super cool
This was very helpful! I'm glad the video went into a little further details with std::forward and ref-qualifiers.
Thanks for the talk
Great presentation, very informative
Nice talk, thank you!
Thanks for the great talk! One question from my side: I reproduced the slide from 38:00 in Compiler Explorer, tried several different compilers and settings, but I couldn't reproduce the copy ctor call in the end, regardless of noexept in the move-ctor signature. So from what I see, when the vector reallocates its memory internally, it always uses the move ctor, which contradictes to the example one the slides and the statement about exception safety of the std-lib. Any comments on this? Thanks a lot 🙂
Best explanation I've seen on std::move. The literature for move semantics is pretty difficult to grasp for me but I found this presentation easy to follow. It all finally clicks. Thank you!
Excellent!
Great! I liked it!
Cool, this vid covers a lot
When passing observer structures around to functions (such as string_view or span), is it better to pass them by copy, move (when possible) or reference?
I might be a little bit late to the party but the general consensus seems to be that you pass by value, with the reason being the same as when you pass an int by value
Fantastic explanation.
Confusion: Andreas explained not to use "move" in return statements because compiler will do RVO. But during "ref-qualifier" explanation, the return statement use "move".
??
NRVO or RVO doesnt apply to functions with && return types so the std::move is required...
When you're sure to receive an R value, which in his case he was, it's safe to uuse std::move because you know it's a temporary
Starts at 1:16
Slide 35, spot the bug on line 8!
Next I'm looking forward to a *true relocation* trait, so that resizing a vector of 100 unique/shared_ptr's is nothing more than a memcpy, and all the old elements don't even call the destructor.
30:39 The terms "destructive move" and "non-destructive move" as used are quite, um, unfortunate because the so-called "destructive move" like in Rust does *not* call the destructor on the original object at all (it just memcpy's) whereas the "non-destructive move" *does* still destruct the object, but just deferred to later. Clearer terms would something like "relocates" and "zombifies".
The language evolves in a wrong way if you need to read a 100 pages book to understand a core feature
Being C++ developer is difficult. I am C++ developer and trying to look for a C++ position, but the recruiter is telling me, "not much C++ jobs in the market". so what's the point continue learn C++ programming skills. The market is requiring many other programming language skills, all is indicating C++ is out of date.
Well if you are a web developer looking for C++ you get what you deserve. Otherwise i would say the jobs for C++ programmers are still there but often you get into them not by knowing the language but knowing the domain where it is used.
It's always funny: std::move does not move anyting
Not related to this talk, but as a more hobbyist programmer the thing I find odd about C++ is just how long it's taken to implement fairly basic features, like abstractions for single instructions. One of the first things I did (like 10 years ago) is figure out how to implement the BSWAP instruction with either compiler instrinsics or inline asm. And I wondered, why isn't there an inherently portable std::endianswap() or something. And in the same header, an implementation defined flag for what the system's native byte order is. Likewise for the other bit rotation functions. It's finally been implemented in C++23, but people have been dealing with big endian byte order on little endian systems in networking and image manipulation forever.
I think what C++ needed was less social maneuvering corporate delegates bringing that structure to its development, and more autism and neuroticism. In my view a large group of people left the language glaringly incomplete for decades. It's actually extremely strange when you think about it. "Write a paper" they say. "Create endian.h, implement byteswap and means of reporting native endian and tagging if needed." There's my paper. I'm a hobbyist and this was the first thing I thought the language could be doing and wasn't. If I just assumed I didn't have the time or expertise required to write a formal paper, I also assume others have done the same. Why do these language lawyers and C++ experts need a formal paper anyway? They know large segments of the language inside and out and are just going to debate about how these components interoperate in committee fashion anyway. It's ridiculous.
Design by committee pressure has probably helped C++ in soem senses, but is also responsible for it lagging considerrably.
God almighty the first 8 minutes were painful. We are not 5 years old. Get on with it.
It is literally called back to basics.
I liked the presentation but I fully agree with you regarding the first 8 minutes, unnecessary
Tbh, the same each year, and also most useless examples!