Enough string_view to hang ourselves
summary
Case study on a 15‑year Windows app, Advanced Installer, modernized to C++17 with clang tooling shows std::string_view saves copies but causes real bugs: storing views in a vector led to dangling references, implicit null‑terminated constructors cost runtime, and auto return type can deduce string_view causing use‑after‑free. Uses include clang‑tidy checks (enable bugprone‑dangling‑handle) and LLVM/Clang tools; guidance is to pass string_view by value for parameters, avoid persisting views in containers, use transparent comparators for maps, and follow proposals like P0936 for safer semantics.
AI-written summary · about
chapters (9)
- 0:00Start
- 10:30C + + 17 String View
- 12:35Why Are We Trying To Avoid Temporary Strings
- 15:12Costly Constructor
- 15:52Standard String
- 22:18Explicit Constructor for Standard String
- 28:25Detecting Dangling References as Handles To Swing Views
- 43:07What Is a Borrow Type
- 49:34Conclusion
related talks
01h 02m“Enough string_view to Hang Ourselves”
01h 04mHow to Use string_view in C++ - Basics, Benefits, and Best Practices
51mTypical C++, but Why?
52mC++ Performance Tips - Cutting Down on Unnecessary Objects
54mTypical C++, But Why?
03mLet's cmakeify the C++ standard library
56mC++17: The Library Features
01h 10mSafe and Readable Code - Monadic Operations in C++23