Rule of DesDeMovA
summary
Explains how C++ special member function rules actually behave using Howard Hinnant’s table and why the language sometimes gives copy semantics where you don't want them, causing slicing for polymorphic bases. Points out that declaring a destructor commonly deletes move assignment, producing types that neither copy nor move — the practical rule of destructor (DesDeMovA). Recommends when to prefer rule of zero or adopt rule of five, and when RAII managers should be move-only resource managers.
AI-written summary · about
related talks
01h 19mSpecial Member Functions in C++
55mBack to Basics: Move Semantics (part 1 of 2)
58mModern C++ Design (part 2 of 2)
58mTo Move or Not to Move - An Interactive Analysis
01h 23mThis is C++ - How to Use the C++ Superpower to Write Better C++ Code
01h 19mThis is C++: Uncompromised Performance, Undefined Behavior, & Move Semantics
55mBreaking Dependencies: Type Erasure - The Implementation Details
27mReturn Value Optimization: Harder Than It Looks