Engineering Distinguished Speaker Series: Howard Hinnant
Why Stack Overflow recommends it
Stack Overflow users link it when explaining C++ move semantics, special member functions, and why copy-and-swap is not always the best way to write assignment operators.
Recommended by 8 people across 11 different months, 2011 to 2024.
What it is
A 70-minute talk by Howard Hinnant, the principal author of C++ move semantics, given at Bloomberg's Engineering Distinguished Speaker Series in 2016. It covers rvalue references, move construction and assignment, the special member functions and when they are generated, and performance trade-offs such as copy-and-swap.
What people said
Strong rec Maxim Egorushkin · 2019-10 · Stack Overflow · on “defining destructor in a class derived from move-only type gives compile-time error when created with emplace_back or push_back of std::vector”
I found your talk Everything you ever wanted to know about move semantics [this video] most insightful. This is straight from that table. ++1
Strong rec user4581301 · 2020-10 · Stack Overflow · on “C++ Difference between: Obj*& vs Obj** vs Obj&&”
Some really good viewing: [this video] . It's mostly focused on move semantics, but to cover that, it dives into rvalue references better than anything else I can remember reading or seeing. Note that my memory sucks and I'll probably remember something as good or better a few weeks from now.
Strong rec user4581301 · 2023-04 · Stack Overflow · on “Importance of universal references in C++”
Howard Hinnant did a great presentation that, if I remember correctly, covers this. Everything you ever wanted to know about move semantics [this video] . If I'm wrong, it's still worth the time spent watching and learning.
Strong rec Hari · 2023-06 · Stack Overflow · on “Constructor implementation preference for move and copy semantics C++”
Howard Hinnant in a talk [this video] highly recommended implementing each special member function individually and not implement one in terms of the other. For performance, he also discouraged the use of the copy-and-swap idiom in the assignment operator, which is similar to the first option shown in the question ( C(std::vector<std::string> s) : _s(std::move(s)) {} ). Such an unified assignment operator can accept both rvalues and lvalues. That is true for this constructor also. He shows empirical evidence based on a class containing a vector (just like in the question). Especially, if the vector in the target has sufficient capacity, copy-and-swap based assignment can be eight times slower tha
Strong rec user4581301 · 2024-03 · Stack Overflow · on “move constructor/assignment for a trivial class in a linked list”
Educational Viewing well worth the time: Howard Hinnant's Everything You Need To Know About Move Semantics presentation [this video]
Recommends Howard Hinnant · 2016-12 · Stack Overflow · on “Do we need move and copy assignment”
without worsening performance or other negative effects? It depends on the data members and base classes of A , and can even depend on the bases and members of A's bases and members. Here is a link to a part of a video that demonstrates that if A has a vector as a data member, then the copy/swap idiom can cost a 70% performance hit for the copy assignment operator on average . This is compared to the much easier approach of defaulting the assignment special members. [this video] class A { std::vector<int> v_; public: // ... }; You can expect string data members to have the same impact as vector data members. If you aren't sure for your A , and if performance is important to you, try it both ways
Recommends badola · 2018-04 · Stack Overflow · on “Linker error for different declarations of default constructors”
This is additional information, and is supplemental to the answer provided by others. There is a difference w.r.t. the context of special member functions, when we use the terms such as defaulted , undeclared and deleted . When a special member function is: undeclared : It does not participate in overload resolution. To use this functionality, just don't declare the special member function. deleted : It participates in overload resolution. It prevents compilation, if used anywhere. To use this functionality, the keyword is delete defaulted : It participates in overload resolution. The default, compiler generated code is provided as the definition. To use this functionality, the keyword is de
Recommends alfC · 2018-07 · Stack Overflow · on “Copy-swap idiom not recommended?”
For a long time time I though that the correct way to implement a copy assignment (for a non trivial class) was to use the copy-swap idiom. struct A{ ... pointer to data A(A const& other){ ... complicated stuff, allocation, loops, etc } void swap(A& other){... cheap stuff ...} A& operator=(A const& other){ A tmp{other}; swap(other); return *this; } }; But then I heard this talk [this video] by Howard Hinnant where he says that the copy-swap idiom is good to fulfill the strong-exception guarrantee but it is an overkill in general. He mentions that here: [this video] So he suggests implement the copy assignment explicitly and have a separate function strong_assing(A& target, A const& source) containing
Recommends Louis Semprini · 2020-09 · Stack Overflow · on “Is the default Move constructor defined as noexcept?”
@HowardHinnant (continued)...so given that rub, I'm not sure if the check is useful in the cases where the programmer hasn't explicitly also written a copy constructor that they know is not `noexcept` (because it's too much brainwork to figure out if the compiler-generated move-constructor would exist (despite your incredibly useful video [this video] ) and also whether the compiler-generated copy constructor would be `noexcept`). It's too bad there is no direct check that ONLY looks at the move constructor.
Recommends user4581301 · 2020-09 · Stack Overflow · on “What's the purpose of typing `= default` at the end of a constructor or operator overloader (ex: copy assignment operator) declaration in a class?”
@GabrielStaples : Howard Hinnant's presentation on Move semantics [this video] has a good discussion on special member functions.