From 441070c203f048a3fca3dcc618b9716e796bcefe Mon Sep 17 00:00:00 2001 From: Bjarne Stroustrup Date: Thu, 28 Jul 2016 09:07:25 -0400 Subject: [PATCH] PRO->PRO and CON->Con they are not acronyms --- CppCoreGuidelines.md | 88 ++++++++++++++++++++++---------------------- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index ecfe9cb..c44a00f 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -1,6 +1,6 @@ # C++ Core Guidelines -July 25, 2016 +July 28, 2016 Editors: @@ -35,7 +35,7 @@ You can [read an explanation of the scope and structure of this Guide](#S-abstra * [Enum: Enumerations](#S-enum) * [R: Resource management](#S-resource) * [ES: Expressions and statements](#S-expr) -* [PER: Performance](#S-performance) +* [Per: Performance](#S-performance) * [CP: Concurrency](#S-concurrency) * [E: Error handling](#S-errors) * [Con: Constants and immutability](#S-const) @@ -49,7 +49,7 @@ Supporting sections: * [A: Architectural Ideas](#S-A) * [N: Non-Rules and myths](#S-not) * [RF: References](#S-references) -* [PRO: Profiles](#S-profile) +* [Pro: Profiles](#S-profile) * [GSL: Guideline support library](#S-gsl) * [NL: Naming and layout](#S-naming) * [FAQ: Answers to frequently asked questions](#S-faq) @@ -322,14 +322,14 @@ Recommended information sources can be found in [the references](#S-references). * [SL: The Standard library](#S-stdlib) * [SF: Source files](#S-source) * [CPL: C-style programming](#S-cpl) -* [PRO: Profiles](#S-profile) +* [Pro: Profiles](#S-profile) * [GSL: Guideline support library](#S-gsl) * [FAQ: Answers to frequently asked questions](#S-faq) Supporting sections: * [NL: Naming and layout](#S-naming) -* [PER: Performance](#S-performance) +* [Per: Performance](#S-performance) * [N: Non-Rules and myths](#S-not) * [RF: References](#S-references) * [Appendix A: Libraries](#S-libraries) @@ -10543,7 +10543,7 @@ This also applies to `%`. * Flag division by an integral value that could be zero -# PER: Performance +# Per: Performance ??? should this section be in the main guide??? @@ -10554,25 +10554,25 @@ Do not blindly try to follow them in general code: achieving the goals of low la Performance rule summary: -* [PER.1: Don't optimize without reason](#Rper-reason) -* [PER.2: Don't optimize prematurely](#Rper-Knuth) -* [PER.3: Don't optimize something that's not performance critical](#Rper-critical) -* [PER.4: Don't assume that complicated code is necessarily faster than simple code](#Rper-simple) -* [PER.5: Don't assume that low-level code is necessarily faster than high-level code](#Rper-low) -* [PER.6: Don't make claims about performance without measurements](#Rper-measure) -* [PER.10: Rely on the static type system](#Rper-type) -* [PER.11: Move computation from run time to compile time](#Rper-Comp) -* [PER.12: Eliminate redundant aliases](#Rper-alias) -* [PER.13: Eliminate redundant indirections](#Rper-indirect) -* [PER.14: Minimize the number of allocations and deallocations](#Rper-alloc) -* [PER.15: Do not allocate on a critical branch](#Rper-alloc0) -* [PER.16: Use compact data structures](#Rper-compact) -* [PER.17: Declare the most used member of a time-critical struct first](#Rper-struct) -* [PER.18: Space is time](#Rper-space) -* [PER.19: Access memory predictably](#Rper-access) -* [PER.30: Avoid context switches on the critical path](#Rper-context) +* [Per.1: Don't optimize without reason](#Rper-reason) +* [Per.2: Don't optimize prematurely](#Rper-Knuth) +* [Per.3: Don't optimize something that's not performance critical](#Rper-critical) +* [Per.4: Don't assume that complicated code is necessarily faster than simple code](#Rper-simple) +* [Per.5: Don't assume that low-level code is necessarily faster than high-level code](#Rper-low) +* [Per.6: Don't make claims about performance without measurements](#Rper-measure) +* [Per.10: Rely on the static type system](#Rper-type) +* [Per.11: Move computation from run time to compile time](#Rper-Comp) +* [Per.12: Eliminate redundant aliases](#Rper-alias) +* [Per.13: Eliminate redundant indirections](#Rper-indirect) +* [Per.14: Minimize the number of allocations and deallocations](#Rper-alloc) +* [Per.15: Do not allocate on a critical branch](#Rper-alloc0) +* [Per.16: Use compact data structures](#Rper-compact) +* [Per.17: Declare the most used member of a time-critical struct first](#Rper-struct) +* [Per.18: Space is time](#Rper-space) +* [Per.19: Access memory predictably](#Rper-access) +* [Per.30: Avoid context switches on the critical path](#Rper-context) -### PER.1: Don't optimize without reason +### Per.1: Don't optimize without reason ##### Reason @@ -10584,7 +10584,7 @@ Some people optimize out of habit or because it's fun. ??? -### PER.2: Don't optimize prematurely +### Per.2: Don't optimize prematurely ##### Reason @@ -10592,7 +10592,7 @@ Elaborately optimized code is usually larger and harder to change than unoptimiz ??? -### PER.3: Don't optimize something that's not performance critical +### Per.3: Don't optimize something that's not performance critical ##### Reason @@ -10605,10 +10605,10 @@ If your program spends most of its time waiting for the web or for a human, opti Put another way: If your program spends 4% of its processing time doing computation A and 40% of its time doing computation B, a 50% improvement on A is only as impactful as a 5% improvement on B. (If you don't even know how much -time is spent on A or B, see PER.1 and PER.2.) +time is spent on A or B, see Per.1 and Per.2.) -### PER.4: Don't assume that complicated code is necessarily faster than simple code +### Per.4: Don't assume that complicated code is necessarily faster than simple code ##### Reason @@ -10641,7 +10641,7 @@ Simple code can be very fast. Optimizers sometimes do marvels with simple code ??? -### PER.5: Don't assume that low-level code is necessarily faster than high-level code +### Per.5: Don't assume that low-level code is necessarily faster than high-level code ##### Reason @@ -10653,7 +10653,7 @@ Low-level code sometimes inhibits optimizations. Optimizers sometimes do marvels ??? -### PER.6: Don't make claims about performance without measurements +### Per.6: Don't make claims about performance without measurements ##### Reason @@ -10673,7 +10673,7 @@ Often, you will be surprised. ??? -### PER.10: Rely on the static type system +### Per.10: Rely on the static type system ##### Reason @@ -10681,27 +10681,27 @@ Type violations, weak types (e.g. `void*`s), and low level code (e.g., manipulat ??? -### PER.11: Move computation from run time to compile time +### Per.11: Move computation from run time to compile time ??? -### PER.12: Eliminate redundant aliases +### Per.12: Eliminate redundant aliases ??? -### PER.13: Eliminate redundant indirections +### Per.13: Eliminate redundant indirections ??? -### PER.14: Minimize the number of allocations and deallocations +### Per.14: Minimize the number of allocations and deallocations ??? -### PER.15: Do not allocate on a critical branch +### Per.15: Do not allocate on a critical branch ??? -### PER.16: Use compact data structures +### Per.16: Use compact data structures ##### Reason @@ -10709,11 +10709,11 @@ Performance is typically dominated by memory access times. ??? -### PER.17: Declare the most used member of a time-critical struct first +### Per.17: Declare the most used member of a time-critical struct first ??? -### PER.18: Space is time +### Per.18: Space is time ##### Reason @@ -10721,7 +10721,7 @@ Performance is typically dominated by memory access times. ??? -### PER.19: Access memory predictably +### Per.19: Access memory predictably ##### Reason @@ -10741,7 +10741,7 @@ Performance is very sensitive to cache performance and cache algorithms favor si for (int c = 0; c < cols; ++c) sum += matrix[r][c]; -### PER.30: Avoid context switches on the critical path +### Per.30: Avoid context switches on the critical path ??? @@ -15853,7 +15853,7 @@ Thanks to the many people who contributed rules, suggestions, supporting informa and see the contributor list on the github. -# PRO: Profiles +# Pro: Profiles A "profile" is a set of deterministic and portably enforceable subset rules (i.e., restrictions) that are designed to achieve a specific guarantee. "Deterministic" means they require only local analysis and could be implemented in a compiler (though they don't need to be). "Portably enforceable" means they are like language rules, so programmers can count on enforcement tools giving the same answer for the same code. @@ -15884,7 +15884,7 @@ To suppress enforcement of a profile check, place a `suppress` annotation on a l Now `raw_find()` can scramble memory to its heart's content. Obviously, suppression should be very rare. -## PRO.safety: Type safety profile +## Pro.safety: Type safety profile This profile makes it easier to construct code that uses types correctly and avoids inadvertent type punning. It does so by focusing on removing the primary sources of type violations, including unsafe uses of casts and unions.