From acf08ddd46ea01f2e7b076c0a385c968354320c4 Mon Sep 17 00:00:00 2001 From: Herb Sutter Date: Thu, 15 Feb 2024 09:54:18 -1000 Subject: [PATCH] Add `#pNN` anchors for P section --- CppCoreGuidelines.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index e8578f7..d7d6737 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -482,7 +482,7 @@ Philosophical rules are generally not mechanically checkable. However, individual rules reflecting these philosophical themes are. Without a philosophical basis, the more concrete/specific/checkable rules lack rationale. -### P.1: Express ideas directly in code +### P.1: Express ideas directly in code ##### Reason @@ -563,7 +563,7 @@ Very hard in general. * flag uses of casts (casts neuter the type system) * detect code that mimics the standard library (hard) -### P.2: Write in ISO Standard C++ +### P.2: Write in ISO Standard C++ ##### Reason @@ -595,7 +595,7 @@ In such cases, control their (dis)use with an extension of these Coding Guidelin Use an up-to-date C++ compiler (currently C++20 or C++17) with a set of options that do not accept extensions. -### P.3: Express intent +### P.3: Express intent ##### Reason @@ -661,7 +661,7 @@ Look for common patterns for which there are better alternatives There is a huge scope for cleverness and semi-automated program transformation. -### P.4: Ideally, a program should be statically type safe +### P.4: Ideally, a program should be statically type safe ##### Reason @@ -691,7 +691,7 @@ For example: * 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 +### P.5: Prefer compile-time checking to run-time checking ##### Reason @@ -735,7 +735,7 @@ better * 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 +### P.6: What cannot be checked at compile time should be checkable at run time ##### Reason @@ -842,7 +842,7 @@ How do we transfer both ownership and all information needed for validating use? * 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 +### P.7: Catch run-time errors early ##### Reason @@ -959,7 +959,7 @@ The physical law for a jet (`e * e < x * x + y * y + z * z`) is not an invariant * Look for structured data (objects of classes with invariants) being converted into strings * ??? -### P.8: Don't leak any resources +### P.8: Don't leak any resources ##### Reason @@ -1012,7 +1012,7 @@ Combine this with enforcement of [the type and bounds profiles](#SS-force) and y * 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 +### P.9: Don't waste time or space ##### Reason @@ -1088,7 +1088,7 @@ Many more specific rules aim at the overall goals of simplicity and elimination * 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.10: Prefer immutable data to mutable data ##### Reason @@ -1099,7 +1099,7 @@ You can't have a data race on a constant. See [Con: Constants and immutability](#S-const) -### P.11: Encapsulate messy constructs, rather than spreading through the code +### P.11: Encapsulate messy constructs, rather than spreading through the code ##### Reason @@ -1149,7 +1149,7 @@ This is a variant of the [subset of superset principle](#R0) that underlies thes * Look for "messy code" such as complex pointer manipulation and casting outside the implementation of abstractions. -### P.12: Use supporting tools as appropriate +### P.12: Use supporting tools as appropriate ##### Reason @@ -1178,7 +1178,7 @@ Be careful not to become dependent on over-elaborate or over-specialized tool ch Those can make your otherwise portable code non-portable. -### P.13: Use support libraries as appropriate +### P.13: Use support libraries as appropriate ##### Reason