C++ Modules and Large-Scale Development (Part 1)
summary
Argues that C++ modules change architecture more than speed, claiming modules must support incremental migration, interoperability with headers, and identical ABI/type identity across both. Lists concrete rules: no cyclic physical dependencies, include your .h first, declare all externally linked constructs in headers, and include anything the client needs (five reasons). Notes modules fix transitive includes but do not provide insulation, and cites a clang-based tool BD-verify used to analyze and rewrite code.
AI-written summary · about
chapters (19)
- 0:00Start
- 2:32Component Based Design
- 4:19Logical Component and a Physical Component
- 8:09Internal versus External Linkage
- 14:16External Linkage
- 19:51Logical Relationships
- 24:45Implied Dependencies
- 25:06Level Numbers
- 26:41Compulsory Fine Grain Reusable Modules
- 27:32Four Reasons To Co-Locate Public Classes in a Module
- 27:50Inheritance
- 28:27Recursive Templates
- 30:05Single Solution
- 33:06Encapsulation versus Insulation
- 38:15Implementation Detail
- 40:19Five Major Reasons for Including a Header in a Header
- 49:43What Is the Migration Path for Modules
- 52:09Logical versus Physical Encapsulation
- 57:26Requirements
related talks
01h 00mSo, you want to use C++ Modules ... cross-platform?
01h 09mC++ Modules: Getting Started Today
01h 02mModern CMake Modules
01h 00m“Deploying C++ modules to 100s of millions of lines of code"
01h 04mC++ Modules - Getting started today
01h 01m10 Problems Large Companies Have Managing C++ Dependencies and How to Solve Them
55mModern CMake for modular design
01h 17mThe Importance of the C++ Build System Target Model