Avoid Misuse of Contracts!
summary
Argues that contract checks exist to catch programmer bugs: in a correct program function contracts are never violated and removing contract checks must not change essential behavior (only performance). Shows that using language or macro CCFs (GSL or future C++ contracts) as input validation or to drive control flow is wrong — examples include inserting into a set inside a predicate and relying on asserts for IO. Recommends testing, defining an application envelope, and avoiding side-effecting predicates.
AI-written summary · about
chapters (27)
- 0:00Introduction
- 0:32What this talk is about
- 1:12Contract terminology
- 3:19Two types of contracts
- 5:00Design by contract
- 11:55John Wake
- 12:29Out of contract
- 15:26Check preconditions
- 16:15How to check
- 18:05Two principles
- 19:10Misuse of contracts
- 19:32Preconditions
- 23:17Side effects in predicates
- 24:20How to check if a value is corrupted
- 25:42Side effects
- 29:30Input validation
- 29:53What is an input
- 30:42Application envelope
- 31:32Example application
- 36:26Application example
- 42:25Additional thoughts
- 46:18Contract assert
- 48:03Application development envelope
- 49:36No side effects
- 51:41Assertions
- 55:42Optimization
- 56:51Conclusion
related talks
01h 17mFunction Contracts in Practice using C++
01h 22mContracts, Safety and Correctness in C++
56mContracts for Dependable C++
01h 05m“Contract Programming in C++(20) (part 2 of 2)”
01h 18mProper Inheritance
01h 21mProgramming with Contracts in C++20
01h 03mCpp Contracts - How Contracts in C++26 Can Improve C++ Code Safety and Correctness
01h 03m“Contract Programming in C++(20) (part 1 of 2)”