How Hard Could It Be? int64 → int64_t
summary
Migrating a companywide int64 alias to int64_t forces concrete fixes not vague guidance: thousands of template-deduction failures and a few hundred virtual-signature mismatches get rewritten via custom clang-tidy checks, thousands of format-string mismatches get eliminated by switching to an Abseil-style constexpr format validation API, static const fields become constexpr to avoid ODR, unit tests catch boolean-overload bugs, and a 2% PGO slowdown is recovered with clang’s profile-remapping; the automated toolchain plus reviews makes the migration complete and production-safe.
AI-written summary · about
chapters (9)
- 0:00Introduction to the project
- 3:58Platform assumptions and constraints
- 8:11Why the type alias change is tricky
- 15:06Reference binding issues
- 22:07Template overload resolution problems
- 33:27String formatting and ODR rules
- 41:14Performance impact of type changes
- 49:37Lessons and future improvements
- 51:42Q&A on PGO and refactoring
related talks
46mHow Hard Could It Be? Lessons Learned from Replacing int64 With int64_t.
01h 01mTime Travel: Applying Gradual Typing to Time Types with Clang's LibTooling
01h 01mMaintainability and Refactoring Impact of Higher-Level Design Features
46mA Type, by Any Other Name
05mMoving an `int` Is Slow: Debug Performance Matters!
27mInfiltrating a Code Base: Moving Toward a Better C
29mintegral types
01h 01mRethinking the Way We Do Templates in C++