Proper Inheritance
summary
Argues that contracts should state exactly which inputs are undefined and which behaviors are essential, shows practical rules (always include header as first substantive line in the cpp, avoid no cyclic physical dependencies and no private access across component boundaries), describes verification via component test drivers and three assert modes, recommends putting invariants asserted in destructor to catch states without per-method overhead, notes the Standards Committee is working on language contracts and points to the open-source BSL assert library.
AI-written summary · about
chapters (25)
- 0:00Start
- 1:04Abstract
- 3:07Review Components
- 4:14Components
- 8:52Avoid Global Namespace
- 10:06Logical Relationships
- 10:47Describe Public Inheritance
- 12:38Implied Dependencies
- 13:53Essential Physical Design Rules
- 14:03Most Important Design Rules
- 18:04Interfaces and Contracts
- 19:25Preconditions
- 21:31Essential Behavior
- 30:13Additional Essential Behavior
- 31:20Verification
- 34:40Postconditions
- 36:42Invariance How Do You Test Invariance
- 40:24How Do We Test Invariants
- 42:03Functions
- 44:54Preconditions Always Imply Post Conditions
- 47:15Exception Agnostic
- 48:03Questions
- 50:13Mutable
- 1:00:06Narrow versus Wide Contracts
- 1:09:21Set Date if Valid
related talks
01h 17mFunction Contracts in Practice using C++
58mAvoid Misuse of Contracts!
56mContracts for Dependable C++
57mPerspectives on Contracts for C++
01h 03m“Contract Programming in C++(20) (part 1 of 2)”
01h 05m“Contract Programming in C++(20) (part 2 of 2)”
01h 27mContractual Disappointment in C++
01h 02mContracts in C++26 - An Insider's Overview