Added bad/good example for C.89, closes #1727

This commit is contained in:
Herb Sutter 2021-04-01 11:37:58 -07:00
parent 8bdb8fe0dc
commit 4f6e11940e

View File

@ -6513,11 +6513,11 @@ The alternative is to make two failure states compare equal and any valid state
##### Note ##### Note
This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, and `>=`. This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, `>=`, and `<=>`.
##### Enforcement ##### Enforcement
* Flag an `operator==()` for which the argument types differ; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`. * Flag an `operator==()` for which the argument types differ; same for other comparison operators: `!=`, `<`, `<=`, `>`, `>=`, and `<=>`.
* Flag member `operator==()`s; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`. * Flag member `operator==()`s; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
### <a name="Rc-eq-base"></a>C.87: Beware of `==` on base classes ### <a name="Rc-eq-base"></a>C.87: Beware of `==` on base classes
@ -6562,11 +6562,11 @@ Of course there are ways of making `==` work in a hierarchy, but the naive appro
##### Note ##### Note
This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, `>=`, and `<=>`. This rule applies to all the usual comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
##### Enforcement ##### Enforcement
* Flag a virtual `operator==()`; same for other comparison operators: `!=`, `<`, `<=`, `>`, `>=`, and `<=>`. * Flag a virtual `operator==()`; same for other comparison operators: `!=`, `<`, `<=`, `>`, and `>=`.
### <a name="Rc-hash"></a>C.89: Make a `hash` `noexcept` ### <a name="Rc-hash"></a>C.89: Make a `hash` `noexcept`
@ -19414,6 +19414,22 @@ It is almost always a bug to mention an unnamed namespace in a header file.
Nothing external can depend on an entity in a nested unnamed namespace. Nothing external can depend on an entity in a nested unnamed namespace.
Consider putting every definition in an implementation source file in an unnamed namespace unless that is defining an "external/exported" entity. Consider putting every definition in an implementation source file in an unnamed namespace unless that is defining an "external/exported" entity.
##### Example; bad
static int f();
int g();
static bool h();
int k();
##### Example; good
namespace {
int f();
bool h();
}
int g();
int k();
##### Example ##### Example
An API class and its members can't live in an unnamed namespace; but any "helper" class or function that is defined in an implementation source file should be at an unnamed namespace scope. An API class and its members can't live in an unnamed namespace; but any "helper" class or function that is defined in an implementation source file should be at an unnamed namespace scope.