ISO Cpp Flashcards
What is the zero-overhead principle?
What you don’t use, you don’t pay for.
What it means to express ideas directly in code?
What is expressed in code has defined semantics and can (in principle) be checked by the compiler and other tools.
What are the enforcements of rule P.1 express ideas directly in code?
1) Use const consistently
2) Flag uses of casts (They neuter the type system)
3) Detect code that mimics the standard library (Look for code that can be done with standard library)
What are the notes of P.2. ISO Standard C++?
1) Avoid dependence on undefined behavior (e.g. undefined order of evaluation)
2) Be aware of construct with implementation defined meaning (e.g. sizeof(int))
3) Using valid ISO C++ does not guarantee portability
What are the P.3. Express intent enforcements?
1) Simple for loops vs. range-for loops
2) f(T*, int) interfaces vs. f(span) interfaces
3) Loop variables in too large scope
4) Naked new and delete
5) Functions with many parameters of built in types
What is the principle and enforcements of P.4: Ideally, a program should be statically type safe?
1) Type errors should be catched during compile time rather than runtime
unions – use variant (in C++17)
casts – minimize their use; templates can help
array decay – use span (from the GSL)
range errors – use span
narrowing conversions – minimize their use and use narrow or narrow_cast (from the GSL) where they are necessary
P.5: Prefer compile-time checking to run-time checking
Code clarity and performance. You don’t need to write error handlers for errors caught at compile time.
Alternative formulation: Don’t postpone to run time what can be done well at compile time.
Enforcement
Look for pointer arguments.
Look for run-time checks for range violations.
P.6: What cannot be checked at compile time should be checkable at run time
Leaving hard-to-detect errors in a program is asking for crashes and bad results.
Flag (pointer, count)-style interfaces (this will flag a lot of examples that can’t be fixed for compatibility reasons)
P.7: Catch run-time errors early
Avoid “mysterious” crashes. Avoid errors leading to (possibly unrecognized) wrong results.
Look at pointers and arrays: Do range-checking early and not repeatedly
Look at conversions: Eliminate or mark narrowing conversions
Look for unchecked values coming from an input
Look for structured data (objects of classes with invariants) being converted into strings
P.8: Don’t leak any resources
Enforcement
Look at pointers: Classify them into non-owners (the default) and owners. Where feasible, replace owners with standard-library resource handles (as in the example above). Alternatively, mark an owner as such using owner from the GSL.
Look for naked new and delete
Look for known resource allocating functions returning raw pointers (such as fopen, malloc, and strdup)
P.9: Don’t waste time or space
Flag an unused return value from a user-defined non-defaulted postfix operator++ or operator– function. Prefer using the prefix form instead. (Note: “User-defined non-defaulted” is intended to reduce noise. Review this enforcement if it’s still too noisy in practice.)
P.10: Prefer immutable data to mutable data
P.11: Encapsulate messy constructs, rather than spreading through the code
Look for “messy code” such as complex pointer manipulation and casting outside the implementation of abstraction
P.12: Use supporting tools as appropriate
Run a static analyzer to verify that your code follows the guidelines you want it to follow.
P.13: Use support libraries as appropriate
