Merge pull request #164 from tkruse/fix-mdstyle6

Fix mdstyle6
This commit is contained in:
Gabriel Dos Reis 2015-09-27 10:02:14 -07:00
commit 07ae55a037

View File

@ -5957,7 +5957,7 @@ Don't leave it undeclared.
This will leak the object used to initialize `p1` (only). 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> <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. and `valid()` checks can be forgotten.
Prefer to use exceptions. Prefer to use exceptions.
**See also**: [discussion](##Sd-noexcept). **See also**: [discussion](#Sd-noexcept).
**Enforcement**: ??? **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. **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**: **Enforcement**:
* 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-concepts"></a> <a name="SS-concepts"></a>
## TPG.concepts: Concept rules ## TPG.concepts: Concept rules
@ -9761,8 +9760,8 @@ There are three major ways to let calling code customize a template.
} }
**Enforcement**: **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> <a name="SS-temp-hier"></a>
## T.temp-hier: Template and hierarchy rules: ## 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). **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**: **Enforcement**:
* Flag all specializations of a function template. Overload instead. * Flag all specializations of a function template. Overload instead.
<a name="S-cpl"></a> <a name="S-cpl"></a>
# CPL: C-style programming # CPL: C-style programming
@ -10557,8 +10553,8 @@ Complicates conversion to use language-supported modules (when they become avail
// file3.h: // file3.h:
#include "file1.h" #include "file1.h"
**Enforcement: Flag all cycles.
**Enforcement**: Flag all cycles.
<a name="Rs-namespace"></a> <a name="Rs-namespace"></a>
### SF.20: Use `namespace`s to express logical structure ### 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 **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> <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**: **Example**:
messing with pointers ??? Messing with pointers
**Note**: If all members are resource handles, rely on the default special operations where possible. **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 * 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 * 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. * 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 `const`'ness wherever possible: member functions, variables and (yippee) const_iterators
* Use `auto` * Use `auto`
* `(size)` vs. `{initializers}` vs. `{Extent{size}}` * `(size)` vs. `{initializers}` vs. `{Extent{size}}`