Mirrors/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2025-12-17 20:54:41 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

Per: fix some typos (#1995)

Browse Source 
* Per.7: fix typo in example
* Per: improve grammar
* Apply suggestions from code review
This commit is contained in:
Max FERGER
2022-12-01 15:15:00 +01:00
committed by GitHub
parent efc6f6eabe
commit ae06b0a056
1 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
CppCoreGuidelines.md
View File

@@ -13888,7 +13888,7 @@ In this, the `sort` interfaces shown here still have a weakness:
They implicitly rely on the element type having less-than (`<`) defined. They implicitly rely on the element type having less-than (`<`) defined.
To complete the interface, we need a second version that accepts a comparison criterion: To complete the interface, we need a second version that accepts a comparison criterion:
// compare elements of c using p // compare elements of c using r
template<random_access_range R, class C> requires sortable<R, C> template<random_access_range R, class C> requires sortable<R, C>
void sort(R&& r, C c); void sort(R&& r, C c);
@@ -13971,7 +13971,7 @@ Once your first initial implementation is complete, review it; once you deploy i
##### Note ##### Note
A need for efficiency does not imply a need for [low-level code](#Rper-low). A need for efficiency does not imply a need for [low-level code](#Rper-low).
High-level code does not imply slow or bloated. High-level code isn't necessarily slow or bloated.
##### Note ##### Note
@@ -13996,7 +13996,7 @@ One question that can be useful is
##### Note ##### Note
This rule does not contradict the [Don't optimize prematurely](#Rper-Knuth) rule. This rule does not contradict the [Don't optimize prematurely](#Rper-Knuth) rule.
It complements it encouraging developers enable later - appropriate and non-premature - optimization, if and where needed. It complements it, encouraging developers to enable later - appropriate and non-premature - optimization, if and where needed.
##### Enforcement ##### Enforcement
@@ -14077,12 +14077,12 @@ There are similar techniques for selecting the optimal function to call.
##### Note ##### Note
The ideal is *not* to try execute everything at compile time. The ideal is *not* to try to execute everything at compile time.
Obviously, most computations depend on inputs so they can't be moved to compile time, Obviously, most computations depend on inputs, so they can't be moved to compile time,
but beyond that logical constraint is the fact that complex compile-time computation can seriously increase compile times but beyond that logical constraint is the fact that complex compile-time computation can seriously increase compile times
and complicate debugging. and complicate debugging.
It is even possible to slow down code by compile-time computation. It is even possible to slow down code by compile-time computation.
This is admittedly rare, but by factoring out a general computation into separate optimal sub-calculations it is possible to render the instruction cache less effective. This is admittedly rare, but by factoring out a general computation into separate optimal sub-calculations, it is possible to render the instruction cache less effective.
##### Enforcement ##### Enforcement
@@ -14130,7 +14130,7 @@ Performance is typically dominated by memory access times.
##### Reason ##### Reason
Performance is very sensitive to cache performance and cache algorithms favor simple (usually linear) access to adjacent data. Performance is very sensitive to cache performance, and cache algorithms favor simple (usually linear) access to adjacent data.
##### Example ##### Example