StarMirror/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2024-03-22 13:30:58 +08:00
Code Issues Projects Releases Wiki Activity

reorder sections C.167 and C.168 to be in numerical ascending order (#1034)

Browse Source
This commit is contained in:
JonasToth 2017-09-28 14:23:28 +02:00 committed by Jonathan Wakely
parent 531952a300
commit 2184c57dd1
1 changed files with 39 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

78
CppCoreGuidelines.md
View File

@ -7853,6 +7853,45 @@ Note that `std::addressof()` always yields a built-in pointer.
Tricky. Warn if `&` is user-defined without also defining `->` for the result type. Tricky. Warn if `&` is user-defined without also defining `->` for the result type.
### <a name="Ro-overload"></a>C.167: Use an operator for an operation with its conventional meaning
##### Reason
Readability. Convention. Reusability. Support for generic code
##### Example
void cout_my_class(const My_class& c) // confusing, not conventional,not generic
{
std::cout << /* class members here */;
}
std::ostream& operator<<(std::ostream& os, const my_class& c) // OK
{
return os << /* class members here */;
}
By itself, `cout_my_class` would be OK, but it is not usable/composable with code that rely on the `<<` convention for output:
My_class var { /* ... */ };
// ...
cout << "var = " << var << '\n';
##### Note
There are strong and vigorous conventions for the meaning most operators, such as
* comparisons (`==`, `!=`, `<`, `<=`, `>`, and `>=`),
* arithmetic operations (`+`, `-`, `*`, `/`, and `%`)
* access operations (`.`, `->`, unary `*`, and `[]`)
* assignment (`=`)
Don't define those unconventionally and don't invent your own names for them.
##### Enforcement
Tricky. Requires semantic insight.
### <a name="Ro-namespace"></a>C.168: Define overloaded operators in the namespace of their operands ### <a name="Ro-namespace"></a>C.168: Define overloaded operators in the namespace of their operands
##### Reason ##### Reason
@ -7918,45 +7957,6 @@ This is a special case of the rule that [helper functions should be defined in t
* Flag operator definitions that are not it the namespace of their operands * Flag operator definitions that are not it the namespace of their operands
### <a name="Ro-overload"></a>C.167: Use an operator for an operation with its conventional meaning
##### Reason
Readability. Convention. Reusability. Support for generic code
##### Example
void cout_my_class(const My_class& c) // confusing, not conventional,not generic
{
std::cout << /* class members here */;
}
std::ostream& operator<<(std::ostream& os, const my_class& c) // OK
{
return os << /* class members here */;
}
By itself, `cout_my_class` would be OK, but it is not usable/composable with code that rely on the `<<` convention for output:
My_class var { /* ... */ };
// ...
cout << "var = " << var << '\n';
##### Note
There are strong and vigorous conventions for the meaning most operators, such as
* comparisons (`==`, `!=`, `<`, `<=`, `>`, and `>=`),
* arithmetic operations (`+`, `-`, `*`, `/`, and `%`)
* access operations (`.`, `->`, unary `*`, and `[]`)
* assignment (`=`)
Don't define those unconventionally and don't invent your own names for them.
##### Enforcement
Tricky. Requires semantic insight.
### <a name="Ro-lambda"></a>C.170: If you feel like overloading a lambda, use a generic lambda ### <a name="Ro-lambda"></a>C.170: If you feel like overloading a lambda, use a generic lambda
##### Reason ##### Reason