diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index d7d6737..8b1219e 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -1,6 +1,6 @@ # C++ Core Guidelines -October 12, 2023 +February 15, 2024 Editors: @@ -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 @@ -5649,7 +5649,7 @@ A class with members that all have default constructors implicitly gets a defaul vector v; }; - X x; // means X{{}, {}}; that is the empty string and the empty vector + X x; // means X{ { }, { } }; that is the empty string and the empty vector Beware that built-in types are not properly default constructed: @@ -8359,7 +8359,7 @@ Subscripting the resulting base pointer will lead to invalid object access and p void use(B*); - D a[] = {{1, 2}, {3, 4}, {5, 6}}; + D a[] = { {1, 2}, {3, 4}, {5, 6} }; B* p = a; // bad: a decays to &a[0] which is converted to a B* p[1].x = 7; // overwrite a[0].y @@ -12543,7 +12543,7 @@ In the rare cases where the slicing was deliberate the code can be surprising. class Shape { /* ... */ }; class Circle : public Shape { /* ... */ Point c; int r; }; - Circle c {{0, 0}, 42}; + Circle c { {0, 0}, 42 }; Shape s {c}; // copy construct only the Shape part of Circle s = c; // or copy assign only the Shape part of Circle @@ -12551,7 +12551,7 @@ In the rare cases where the slicing was deliberate the code can be surprising. { dest = src; } - Circle c2 {{1, 1}, 43}; + Circle c2 { {1, 1}, 43 }; assign(c, c2); // oops, not the whole state is transferred assert(c == c2); // if we supply copying, we should also provide comparison, // but this will likely return false @@ -15891,7 +15891,7 @@ To make error handling systematic, robust, and non-repetitive. void use() { - Foo bar {{Thing{1}, Thing{2}, Thing{monkey}}, {"my_file", "r"}, "Here we go!"}; + Foo bar { {Thing{1}, Thing{2}, Thing{monkey} }, {"my_file", "r"}, "Here we go!"}; // ... }