C++ Trivial Relocation Through Time
summary
Argument: letting containers legally relocate objects by copying bytes instead of calling move+destroy lets implementations replace per-element move loops with a single memcpy, cutting vector growth cost — a quick benchmark on std::string shows 2.8× speedup. Multiple WG21 proposals (N4034, P0023, P1029, P1144, P2786) and library hacks (Facebook Folly, Bloomberg BDE) exist; reference implementations and a Silang-based stdlib variant demonstrate feasibility but the change requires a lifetime-model fix to avoid current undefined behavior for trivially relocatable types.
AI-written summary · about
chapters (18)
- 0:00Introduction to speaker
- 1:00Agenda and motivation
- 1:42Vector growth mechanics
- 3:54C++11 move constructors
- 5:09Memcopy benefits
- 7:28Trivially copyable types
- 10:08Defining trivial relocation
- 12:56Third-party library usage
- 15:04Standard library pitfalls
- 17:43Value of language support
- 19:43History: Pablo's proposal
- 25:18History: Denny's proposal
- 30:04History: Niall's proposal
- 35:05Ongoing efforts
- 39:02Commonalities and traits
- 44:30Differences and challenges
- 57:40Conclusion
- 1:00:03Q&A
related talks
42mThe Nightmare of Move Semantics for Trivial C++ Classes
01h 23mRethink Polymorphism in C++
55mGreat C++ is_trivial
52mC++ Performance Tips - Cutting Down on Unnecessary Objects
05mMoving an `int` Is Slow: Debug Performance Matters!
01h 02m“Lightweight Object Persistence With Relocatable Heaps in Modern C++"
01h 19mThis is C++: Uncompromised Performance, Undefined Behavior, & Move Semantics
59mBack to Basics: Move Semantics