C++ API & ABI versioning
summary
Defines API as a contract and ABI as how binaries talk, and shows which exact edits break what: changing a function signature triggers name mangling mismatches and link errors, reordering or adding virtuals corrupts vtable layout, and adding or moving struct members changes sizes/offsets and breaks binaries. Recommends clang tooling to generate AST-based patches for automated client upgrades, using inline namespaces and PIMPL to preserve ABI, and contrasts traditional semantic versioning with Live at Head and Google’s bot-driven migration workflow.
AI-written summary · about
chapters (34)
- 0:00Intro
- 1:55Questions to ask yourself
- 6:43Reasonable use
- 9:38API
- 14:05Categorizing Changes
- 15:28Contract Changes
- 17:03Practical Impact
- 18:29Nonbreaking Impact
- 19:05Undefined Behavior
- 21:34Breaking Changes
- 26:18No compiler ISO
- 26:34ABI
- 28:17Mangling
- 31:22Symbol ID
- 32:29Inline functions
- 35:11Table layouts
- 37:26Binary representation of types
- 38:10Example
- 41:04General rule
- 41:50Compatibility with C
- 42:45ABI padding
- 44:06Semantic versioning
- 45:59Binary compatibility
- 47:36Traditional ABI
- 48:04Major minor patch
- 48:49Minor ABI patch
- 49:09ABI compatibility
- 49:28Allow upgrades
- 52:22Databydesign
- 54:08Documentation
- 55:34ABI in versioning
- 56:36Inline namespaces
- 57:15Inline namespace example
- 59:26Dependencies
related talks
39mWhat Is an ABI, and Why Should You Care?
54mThe C++ ABI From the Ground Up
01h 06mWhat is an ABI, and Why is Breaking it Bad?
47mAPI Design Principles
26mDon't break your users: keep your API/ABI stable!
50mHow to break an ABI and keep your users happy
40mHow to Build Binary-Compatible APIs in Compiled Languages?
01h 31m“C++ as a "Live at Head" Language”