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

Section C.over was marked as a chapter.

Browse Source 
The chapter on templates T was also abbreviated as TPG and TCP.
Anchor names corrected.
Rule T.26 was designated as T.27.
Missing ) added.
added missing references
The rules T.12 and T.13 were designated as T.14 and T.15 in the summary.
This commit is contained in:
uli 2015-10-18 10:47:45 +02:00 committed by uli
parent acb20cff05
commit 26e006b148
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
CppCoreGuidelines.md
View File

@ -1388,7 +1388,7 @@ Use the ISO Concepts TS style of requirements specification. For example:
Soon (maybe in 2016), most compilers will be able to check `requires` clauses once the `//` is removed. Soon (maybe in 2016), most compilers will be able to check `requires` clauses once the `//` is removed.
**See also**: See [generic programming](???) and [???](???) **See also**: See [generic programming](#SS-GP) and [concepts](#SS-t-concepts).
##### Enforcement ##### Enforcement
@ -1437,7 +1437,7 @@ We don't consider "performance" a valid reason not to use exceptions.
* A good rule for performance critical code is to move checking outside the critical part of the code ([checking](#Rper-checking)). * 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. * In the longer term, more regular code gets better optimized.
**See also**: I.??? and I.??? for reporting precondition and postcondition violations. **See also**: [I.5](#Ri-pre) and [I.7](#Ri-post) for reporting precondition and postcondition violations.
##### Enforcement ##### Enforcement
@ -6001,7 +6001,7 @@ Subscripting the resulting base pointer will lead to invalid object access and p
* Flag all combinations of array decay and base to derived conversions. * Flag all combinations of array decay and base to derived conversions.
* Pass an array as a `span` rather than as a pointer, and don't let the array name suffer a derived-to-base conversion before getting into the `span` * Pass an array as a `span` rather than as a pointer, and don't let the array name suffer a derived-to-base conversion before getting into the `span`
# <a name="SS-overload"></a> C.over: Overloading and overloaded operators ## <a name="SS-overload"></a> C.over: Overloading and overloaded operators
You can overload ordinary functions, template functions, and operators. You can overload ordinary functions, template functions, and operators.
You cannot overload function objects. You cannot overload function objects.
@ -10328,7 +10328,7 @@ In a class template, nonvirtual functions are only instantiated if they're used
* Flag a class template that declares new (non-inherited) virtual functions. * Flag a class template that declares new (non-inherited) virtual functions.
## <a name="SS-tpg-concepts"></a> TPG.concepts: Concept rules ## <a name="SS-concepts"></a> T.concepts: Concept rules
Concepts is a facility for specifying requirements for template arguments. Concepts is a facility for specifying requirements for template arguments.
It is an [ISO technical specification](#Ref-conceptsTS), but not yet supported by currently shipping compilers. It is an [ISO technical specification](#Ref-conceptsTS), but not yet supported by currently shipping compilers.
@ -10339,8 +10339,8 @@ Concept use rule summary:
* [T.10: Specify concepts for all template arguments](#Rt-concepts) * [T.10: Specify concepts for all template arguments](#Rt-concepts)
* [T.11: Whenever possible use standard concepts](#Rt-std-concepts) * [T.11: Whenever possible use standard concepts](#Rt-std-concepts)
* [T.14: Prefer concept names over `auto`](#Rt-auto) * [T.12: Prefer concept names over `auto`](#Rt-auto)
* [T.15: Prefer the shorthand notation for simple, single-type argument concepts](#Rt-shorthand) * [T.13: Prefer the shorthand notation for simple, single-type argument concepts](#Rt-shorthand)
* ??? * ???
Concept definition rule summary: Concept definition rule summary:
@ -10446,7 +10446,7 @@ Designing a useful concept is challenging.
Hard. Hard.
* Look for unconstrained arguments, templates that use "unusual"/non-standard concepts, templates that use "homebrew" concepts without axioms. * Look for unconstrained arguments, templates that use "unusual"/non-standard concepts, templates that use "homebrew" concepts without axioms.
* Develop a concept-discovery tool (e.g., see [an early experiment](http://www.stroustrup.com/sle2010_webversion.pdf). * Develop a concept-discovery tool (e.g., see [an early experiment](http://www.stroustrup.com/sle2010_webversion.pdf)).
### <a name="Rt-auto"></a> T.12: Prefer concept names over `auto` for local variables ### <a name="Rt-auto"></a> T.12: Prefer concept names over `auto` for local variables
@ -10490,7 +10490,7 @@ The shorter versions better match the way we speak. Note that many templates don
* Not feasible in the short term when people convert from the `<typename T>` and `<class T`> notation. * Not feasible in the short term when people convert from the `<typename T>` and `<class T`> notation.
* Later, flag declarations that first introduces a typename and then constrains it with a simple, single-type-argument concept. * Later, flag declarations that first introduces a typename and then constrains it with a simple, single-type-argument concept.
## <a name="SS-concept-def"></a> T.con-def: Concept definition rules ## <a name="SS-concepts-def"></a> T.concepts.def: Concept definition rules
??? ???
@ -10727,7 +10727,7 @@ The compiler will select the overload and emit an appropriate error.
* Flag pairs of functions with `C<T>` and `!C<T>` constraints * Flag pairs of functions with `C<T>` and `!C<T>` constraints
* Flag all constraint negation * Flag all constraint negation
### <a name="Rt-use"></a> T.27: Prefer to define concepts in terms of use-patterns rather than simple syntax ### <a name="Rt-use"></a> T.26: Prefer to define concepts in terms of use-patterns rather than simple syntax
##### Reason ##### Reason
@ -10959,7 +10959,7 @@ This rule should not be necessary; the committee cannot agree on how to fix ADL,
??? unfortunately this will get many false positives; the standard library violates this widely, by putting many unconstrained templates and types into the single namespace `std` ??? unfortunately this will get many false positives; the standard library violates this widely, by putting many unconstrained templates and types into the single namespace `std`
## <a name="SS-temp-def"></a> TCP.def: Template definitions ## <a name="SS-temp-def"></a> T.def: Template definitions
??? ???
@ -14021,7 +14021,7 @@ Now `Named` has a default constructor, a destructor, and efficient copy and move
##### Enforcement ##### Enforcement
In general, a tool cannot know if a class is a resource handle. However, if a class has some of [the default operations](???), it should have all, and if a class has a member that is a resource handle, it should be considered a resource handle. In general, a tool cannot know if a class is a resource handle. However, if a class has some of [the default operations](#SS-ctor), it should have all, and if a class has a member that is a resource handle, it should be considered a resource handle.
### <a name="Cr-list"></a> If a class is a container, give it an initializer-list constructor ### <a name="Cr-list"></a> If a class is a container, give it an initializer-list constructor