Please log in to watch this conference skillscast.
Move semantics, introduced with C++11, has become a hallmark of modern C++ programming. However, it also complicates the language in many ways. Even after several years of support, experienced programmers struggle with all details of move semantics.
While I took the time to write up all the facts and details in my new book "C++ Move Semantics - The Complete Guide" (cppmove.com), I learned a lot I wasn't aware of (note that the final book has 260 pages).
This talk is about a very simple class to demonstrate some remarkable aspects of move semantics. We will see some tricky features and traps to understand C++ better.
Question: Is it a compiler error if you use noexcept but the code could throw?
Answer: If you specify noexcept, you know what you do. The compiler could check but note that you know better whether exceptions might be thrown. You might already know that enough memory is allocated or that an index is valid. So if the compiler would give a warning you could get a lot of false positives.
If AT RUNTIME there is an exception so that your guarantee is broken, terminate() is called to abort() the program.
Question: "C++ is tricky, I know" - you just said. As a non-C++ user, it looks terrifying! Can C++ copy the goodness of Rust and make me safer without so much brain space requirement?
Answer: Well, use Rust if you can and it makes more sense for you! C++ is very very fast but still backward compatible to C (so almost 50 years old now). That comes with a price. Newer programming languages can of course learn from C++ and make it better. And yes, we know that we have things we would better not have in C++, but backward compatibility is an important argument.
So far according to the number of programmers (more than 4 million) and tool support and so on there is still no new general purpose language that replaces C++. But that might change and in your context you might be able to use something else.
Question: I'm at least half serious about "Can C++ absorb Rust?" because I know that C++11 changed how C++ programmers should use C++ and every new version does the same. So far, nobody has deprecated the original C++ features, but could you take the Rust "Edition" idea and turn off backward compatibility when the source has a "use only new stuff" switch in it? Then after some time there would only be new C++ code and the amount of things a programmer has to get correct for C++ code to work would be much smaller.
Answer: Believe me, we all would LOVE to go that path. The problem is that too much code is already written. So we would have at least a period of 10 years of overlap for each replaced feature. We can deprecate and remove things. But everybody asks to keep another thing alive. And where do we stop? It is a huge problem. And we don't want to have the Python effect, havcing de-facto two Pythons now. Especially as our world is far more complex (regarding code dependencies) We started at a few places to replace old stuff. We e.g have a new basic thread type and new mutex types. And the new model of executors will replace old approaches of multithreading with the upcoming versions. We discussed introducing std2 with C++20 ranges, but it turned out to introduce a long chain of consequences (e.g. do we need a new string type and what is with the old one...). IMO, this discussion is over.
Question: I also liked the speed comparison you did between the copy and move.
So often in other languages, developers treat speed as an afterthought.
Answer: I think we in the standard committee know that speed and performance is THE reason to use C++. So, there is definitely no goal to become like Java or Python. The goal is to focus on the strength of the language and at the same time try the best we can to ensure that the language is still usable and not a problem in itself. Yes, sometimes we fail. Usually, for good reasons. You are invited to help. This is a community driven language. We don't have a chief architect. So at the end it is all your fault, you didn't help us to make things better :wink:
The C++ standards committee is open for everybody.
Question: I think some of us have guessed at how much work it would be and have "bravely run away"!
Answer: Oh yes, it is. But sometimes it's not...And in these times even in C++ there are no easy answers (as in politics). It needs careful work and effort. There is one thing I learned over all these years working on C++ with people all over the world (including Australia): Complex good things need input by everybody and take time.
YOU MAY ALSO LIKE: