C++ Modules and Large-Scale Development
summary
Explains why C++20 modules change architecture more than syntax, argues modules become better components and must be additive, hierarchical, incremental, interoperable to be usable in large legacy code, gives concrete component rules (header-first include, declare externally linked definitions, five cases that force header includes), warns modules do not magically prevent downstream recompilation but do fix transitive includes, outlines migration stance: incremental dual consumability as modules and headers and flags remaining tooling and contracts work.
AI-written summary · about
chapters (23)
- 0:00Introduction
- 1:03Abstract
- 4:20Components
- 8:03External Linkage
- 12:05What is Linkage
- 21:10Binding
- 27:14Relationships
- 30:03Pointless
- 32:25Point in Name Only
- 33:24Physical Dependencies
- 34:51Level Numbers
- 37:26Physical Design
- 37:52Design Imperatives
- 38:43No longdistance friendship
- 39:33Colocating public classes
- 40:12Iterators
- 41:46Single Solution
- 42:00Hierarchy of Solutions
- 45:51Flea on an Elephant
- 47:37Insulation
- 47:59Encapsulation
- 49:13Insulated
- 49:55Hierarchical Reuse
related talks
59mC++ Modules and Large-Scale Development
01h 30mC++ Modules and Large-Scale Development
01h 04mProgramming with C++ Modules: Guide for the Working
01h 01mLarge Scale C++ with Modules: What You Should Know
58mKnockin' on Header's Door: An Overview of C++ Modules
34mPractical C++20 Modules and the future of tooling around C++ Modules
01h 11mA Practical Introduction to C++20's Modules
01h 33mCommittee Fireside Chat