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

Fixed typos (#1876)

Browse Source
This commit is contained in:
Hyuk Myeong
2022-01-21 06:10:52 +09:00
committed by GitHub
parent 5f393d53af
commit 1a57ff0226
1 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
CppCoreGuidelines.md
View File

@@ -13107,10 +13107,10 @@ Helps make style consistent and conventional.
By definition, a condition in an `if`-statement, `while`-statement, or a `for`-statement selects between `true` and `false`. By definition, a condition in an `if`-statement, `while`-statement, or a `for`-statement selects between `true` and `false`.
A numeric value is compared to `0` and a pointer value to `nullptr`. A numeric value is compared to `0` and a pointer value to `nullptr`.
// These all mean "if `p` is not `nullptr`" // These all mean "if p is not nullptr"
if (p) { ... } // good if (p) { ... } // good
if (p != 0) { ... } // redundant `!=0`; bad: don't use 0 for pointers if (p != 0) { ... } // redundant !=0, bad: don't use 0 for pointers
if (p != nullptr) { ... } // redundant `!=nullptr`, not recommended if (p != nullptr) { ... } // redundant !=nullptr, not recommended
Often, `if (p)` is read as "if `p` is valid" which is a direct expression of the programmers intent, Often, `if (p)` is read as "if `p` is valid" which is a direct expression of the programmers intent,
whereas `if (p != nullptr)` would be a long-winded workaround. whereas `if (p != nullptr)` would be a long-winded workaround.
@@ -13167,10 +13167,10 @@ would not in itself save you.
The opposite condition is most easily expressed using a negation: The opposite condition is most easily expressed using a negation:
// These all mean "if `p` is `nullptr`" // These all mean "if p is nullptr"
if (!p) { ... } // good if (!p) { ... } // good
if (p == 0) { ... } // redundant `== 0`; bad: don't use `0` for pointers if (p == 0) { ... } // redundant == 0, bad: don't use 0 for pointers
if (p == nullptr) { ... } // redundant `== nullptr`, not recommended if (p == nullptr) { ... } // redundant == nullptr, not recommended
##### Enforcement ##### Enforcement
@@ -17479,7 +17479,7 @@ The rule supports the view that a concept should reflect a (mathematically) cohe
// ... and the other comparison operators ... // ... and the other comparison operators ...
Minimal operator+(const Convenient&, const Convenient&); Minimal operator+(const Convenient&, const Convenient&);
// .. and the other arithmetic operators ... // ... and the other arithmetic operators ...
void f(const Convenient& x, const Convenient& y) void f(const Convenient& x, const Convenient& y)
{ {
@@ -18980,7 +18980,7 @@ You can't partially specialize a function template per language rules. You can f
##### Reason ##### Reason
If you intend for a class to match a concept, verifying that early saves users pain. If you intend for a class to match a concept, verifying that early saves users' pain.
##### Example ##### Example
@@ -19519,7 +19519,7 @@ For example:
#include <random> #include <random>
#include <vector> #include <vector>
a user can now get that set of declarations with a single `#include`" a user can now get that set of declarations with a single `#include`
#include "basic_std_lib.h" #include "basic_std_lib.h"
@@ -22295,7 +22295,7 @@ Never allow an error to be reported from a destructor, a resource deallocation f
void test() void test()
{ {
std::array<Nefarious, 10> arr; // this line can std::terminate(!) std::array<Nefarious, 10> arr; // this line can std::terminate()
} }
The behavior of arrays is undefined in the presence of destructors that throw because there is no reasonable rollback behavior that could ever be devised. Just think: What code can the compiler generate for constructing an `arr` where, if the fourth object's constructor throws, the code has to give up and in its cleanup mode tries to call the destructors of the already-constructed objects ... and one or more of those destructors throws? There is no satisfactory answer. The behavior of arrays is undefined in the presence of destructors that throw because there is no reasonable rollback behavior that could ever be devised. Just think: What code can the compiler generate for constructing an `arr` where, if the fourth object's constructor throws, the code has to give up and in its cleanup mode tries to call the destructors of the already-constructed objects ... and one or more of those destructors throws? There is no satisfactory answer.