From 8eb26fc8ddd97be06bc471685f5a5211a8eed64c Mon Sep 17 00:00:00 2001 From: Treb Connell Date: Fri, 25 Sep 2015 11:56:51 -0700 Subject: [PATCH] Fix typos. I don't think these are fixed by other PR's --- CppCoreGuidelines.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 3493973..b9cd95b 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -1232,7 +1232,7 @@ Ideally, that `Ensures` should be part of the interface that's not easily done. -### I.10: Use exceptions to signal a failure to perform an required task +### I.10: Use exceptions to signal a failure to perform a required task **Reason**: It should not be possible to ignore an error because that could leave the system or a computation in an undefined (or unexpected) state. This is a major source of errors. @@ -1268,7 +1268,7 @@ consider using a style that returns a pair of values: **Note**: We don't consider "performance" a valid reason not to use exceptions. * Often, explicit error checking and handling consume as much time and space as exception handling. -* Often, cleaner code yield better performance with exceptions (simplifying the tracing of paths through the program and their optimization). +* Often, cleaner code yields better performance with exceptions (simplifying the tracing of paths through the program and their optimization). * A good rule for performance critical code is to move checking outside the critical part of the code ([checking](#Rper-checking)). * In the longer term, more regular code gets better optimized. @@ -1283,7 +1283,7 @@ consider using a style that returns a pair of values: ### I.11: Never transfer ownership by a raw pointer (`T*`) -**Reason**: if there is any doubt whether the caller or the callee owns an object, leaks or premature destruction will occur. +**Reason**: If there is any doubt whether the caller or the callee owns an object, leaks or premature destruction will occur. **Example**: Consider