mirror of
https://github.com/isocpp/CppCoreGuidelines.git
synced 2024-03-22 13:30:58 +08:00
commit
07ae55a037
|
@ -5957,7 +5957,7 @@ Don't leave it undeclared.
|
|||
|
||||
This will leak the object used to initialize `p1` (only).
|
||||
|
||||
**Enforcement:** (Simple) Warn if the return value of `new` or a function call with return value of pointer type is assigned to a raw pointer.
|
||||
**Enforcement**: (Simple) Warn if the return value of `new` or a function call with return value of pointer type is assigned to a raw pointer.
|
||||
|
||||
|
||||
<a name="Rr-unique"></a>
|
||||
|
@ -8377,7 +8377,7 @@ doesn't allow for implicit propagation of "exceptions" (`valid()` checks),
|
|||
and `valid()` checks can be forgotten.
|
||||
Prefer to use exceptions.
|
||||
|
||||
**See also**: [discussion](##Sd-noexcept).
|
||||
**See also**: [discussion](#Sd-noexcept).
|
||||
|
||||
**Enforcement**: ???
|
||||
|
||||
|
@ -8983,10 +8983,9 @@ See [Stable base](#Rt-abi).
|
|||
**Note**: In a class template, nonvirtual functions are only instantiated if they're used -- but virtual functions are instantiated every time. This can bloat code size, and may overconstrain a generic type by instantiating functionality that is never needed. Avoid this, even though the standard facets made this mistake.
|
||||
|
||||
**Enforcement**:
|
||||
|
||||
* Flag a class template that declares new (non-inherited) virtual functions.
|
||||
|
||||
|
||||
|
||||
<a name="SS-concepts"></a>
|
||||
## TPG.concepts: Concept rules
|
||||
|
||||
|
@ -9761,8 +9760,8 @@ There are three major ways to let calling code customize a template.
|
|||
}
|
||||
|
||||
**Enforcement**:
|
||||
* In a template, flag an unqualified call to a nonmember function that passes a variable of dependent type when there is a nonmember function of the same name in the template's namespace.
|
||||
|
||||
* In a template, flag an unqualified call to a nonmember function that passes a variable of dependent type when there is a nonmember function of the same name in the template's namespace.
|
||||
|
||||
<a name="SS-temp-hier"></a>
|
||||
## T.temp-hier: Template and hierarchy rules:
|
||||
|
@ -10237,12 +10236,9 @@ Of course, range-for is better still where it does what you want.
|
|||
**Exceptions**: If you do have a valid reason to specialize a function template, just write a single function template that delegates to a class template, then specialize the class template (including the ability to write partial specializations).
|
||||
|
||||
**Enforcement**:
|
||||
|
||||
* Flag all specializations of a function template. Overload instead.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<a name="S-cpl"></a>
|
||||
# CPL: C-style programming
|
||||
|
||||
|
@ -10287,8 +10283,8 @@ It provides better support for high-level programming and often generates faster
|
|||
|
||||
**Enforcement**:
|
||||
|
||||
* Flag if using a build mode that compiles code as C.
|
||||
* The C++ compiler will enforce that the code is valid C++ unless you use C extension options.
|
||||
* Flag if using a build mode that compiles code as C.
|
||||
* The C++ compiler will enforce that the code is valid C++ unless you use C extension options.
|
||||
|
||||
|
||||
<a name="Rcpl-interface"></a>
|
||||
|
@ -10557,8 +10553,8 @@ Complicates conversion to use language-supported modules (when they become avail
|
|||
// file3.h:
|
||||
#include "file1.h"
|
||||
|
||||
**Enforcement: Flag all cycles.
|
||||
|
||||
**Enforcement**: Flag all cycles.
|
||||
|
||||
<a name="Rs-namespace"></a>
|
||||
### SF.20: Use `namespace`s to express logical structure
|
||||
|
@ -11994,7 +11990,9 @@ In general, however, avoid concrete base classes (see Item 35). For example, `un
|
|||
**References**: [[C++CS]](#C++CS) Item 50, [[Cargill92]](#Cargill92) pp. 77-79, 207¸ [[Cline99]](#Cline99) §21.06, 21.12-13¸ [[Henricson97]](#Henricson97) pp. 110-114¸ [[Koenig97]](#Koenig97) Chapters 4, 11¸ [[Meyers97]](#Meyers97) §14¸ [[Stroustrup00]](#Stroustrup00) §12.4.2¸ [[Sutter02]](#Sutter02) §27¸ [[Sutter04]](#Sutter04) §18
|
||||
|
||||
|
||||
### <a name="Sd-noexcept"></a> Dicussion: Usage of noexecpt
|
||||
|
||||
???
|
||||
|
||||
|
||||
<a name="Sd-never-fail"></a>
|
||||
|
@ -12315,7 +12313,7 @@ The `string`s of `v` are destroyed upon exit from `bad()` and so is `v` itself.
|
|||
|
||||
**Example**:
|
||||
|
||||
messing with pointers
|
||||
??? Messing with pointers
|
||||
|
||||
**Note**: If all members are resource handles, rely on the default special operations where possible.
|
||||
|
||||
|
@ -12361,7 +12359,7 @@ Aternatively, we will decide that no change is needed and delete the entry.
|
|||
* Avoid implicit conversions
|
||||
* Const member functions should be thread safe "¦ aka, but I don't really change the variable, just assign it a value the first time its called "¦ argh
|
||||
* Always initialize variables, use initialization lists for member variables.
|
||||
* Anyone writing a public interface which takes or returns void* should have their toes set on fire. Â Â That one has been a personal favourite of mine for a number of years. :)
|
||||
* Anyone writing a public interface which takes or returns void* should have their toes set on fire. That one has been a personal favourite of mine for a number of years. :)
|
||||
* Use `const`'ness wherever possible: member functions, variables and (yippee) const_iterators
|
||||
* Use `auto`
|
||||
* `(size)` vs. `{initializers}` vs. `{Extent{size}}`
|
||||
|
|
Loading…
Reference in New Issue
Block a user