Mirrors/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2025-12-17 12:44:42 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix broken anchor names

Browse Source 
which are referred by links with different names.
This commit is contained in:
Kazutoshi SATODA
2015-09-22 21:52:27 +09:00
parent 2e5b16736b
commit f739719e7b
1 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
CppCoreGuidelines.md
View File

@@ -893,7 +893,7 @@ See also
* [E: Error handling](#S-errors)
* [T: Templates and generic programming](#S-templates)
<a name="Ri-expicit"></a>
<a name="Ri-explicit"></a>
### I.1: Make interfaces explicit
**Reason**: Correctness. Assumptions not stated in an interface are easily overlooked and hard to test.
@@ -5832,7 +5832,7 @@ If you have a naked `new`, you probably need a naked `delete` somewhere, so you
**Enforcement**: (Simple) Warn on any explicit use of `new` and `delete`. Suggest using `make_unique` instead.
<a name ="Rr-immediate alloc"></a>
<a name ="Rr-immediate-alloc"></a>
### R.12: Immediately give the result of an explicit resource allocation to a manager object
**Reason**: If you don't, an exception or a return may lead to a leak.
@@ -5865,7 +5865,7 @@ The use of the file handle (in `ifstream`) is simple, efficient, and safe.
* Flag explicit allocations used to initialize pointers (problem: how many direct resource allocations can we recognize?)
<a name ="Rr-single alloc"></a>
<a name ="Rr-single-alloc"></a>
### R.13: Perform at most one explicit resource allocation in a single expression statement
**Reason**: If you perform two explicit resource allocations in one statement,
@@ -5999,7 +5999,7 @@ The `make_shared()` version mentions `X` only once, so it is usually shorter (as
**Enforcement**: (Simple) Warn if a `shared_ptr` is constructed from the result of `new` rather than `make_shared`.
<a name ="Rr-make_shared"></a>
<a name ="Rr-make_unique"></a>
### Rule R.23: Use `make_unique()` to make `unique_ptr`s
**Reason**: for convenience and consistency with `shared_ptr`.
@@ -7086,7 +7086,7 @@ Even if we hadn't left a well-know bug in `SQUARE` there are much better behaved
**Enforcement**: Scream when you see a lower case macro.
<a name="#Res-ellipses"></a>
<a name="Res-ellipses"></a>
### ES.40: Don't define a (C-style) variadic function
**Reason**: Not type safe. Requires messy cast-and-macro-laden code to get working right.
@@ -9423,7 +9423,7 @@ This saves the user of `Value_type` from having to know the technique used to im
* ???
<a name="Rt-alias"></a>
<a name="Rt-using"></a>
### T.43: Prefer `using` over `typedef` for defining aliases
**Reason**: Improved readability: With `using`, the new name comes first rather than being embedded somewhere in a declaration.
@@ -9691,7 +9691,7 @@ Specialization offers a powerful mechanism for providing alternative implementat
**Enforcement**: ???
<a name="Rt-specialization"></a>
<a name="Rt-enable_if"></a>
### T.66: Use selection using `enable_if` to optionally define a function
**Reason**: ???
@@ -11471,7 +11471,7 @@ Comments are not updates as consistently as code.
**Enforcement**: Build an AI program that interprets colloquial English text and see if what is said could be better expressed in C++.
<a name="Rl-comments intent"></a>
<a name="Rl-comments-intent"></a>
### NL.2: State intent in comments
**Reason**: Code says what is done, not what is supposed to be done. Often intent can be stated more clearly and concisely than the implementation.
@@ -11487,7 +11487,7 @@ Comments are not updates as consistently as code.
**Note**: If the comment and the code disagrees, both are likely to be wrong.
<a name="Rl-comments crisp"></a>
<a name="Rl-comments-crisp"></a>
### NL.3: Keep comments crisp
**Reason**: Verbosity slows down understanding and makes the code harder to read by spreading it around in the source file.
@@ -11510,7 +11510,7 @@ Comments are not updates as consistently as code.
Enforcement: Use a tool.
<a name="Rl-name type"></a>
<a name="Rl-name-type"></a>
### NL.5 Don't encode type information in names
**Rationale**: If names reflects type rather than functionality, it becomes hard to change the types used to provide that functionality.
@@ -11542,7 +11542,7 @@ This is not evil.
This is not evil.
<a name="Rl-name length"></a>
<a name="Rl-name-length"></a>
### NL.7: Make the length of a name roughly proportional to the length of its scope
**Rationale**: ???