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

fix bad hyphen for standard-library as adjective

Browse Source
This commit is contained in:
Thibault Kruse 2017-06-25 12:37:55 +09:00
parent f1971b1401
commit 00f9e9ae50
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
CppCoreGuidelines.md
View File

@ -3645,7 +3645,7 @@ We mention this only because of the persistence of this error in the community.
The convention for operator overloads (especially on value types) is for The convention for operator overloads (especially on value types) is for
`operator=(const T&)` to perform the assignment and then return (non-const) `operator=(const T&)` to perform the assignment and then return (non-const)
`*this`. This ensures consistency with standard library types and follows the `*this`. This ensures consistency with standard-library types and follows the
principle of "do as the ints do." principle of "do as the ints do."
##### Note ##### Note
@ -5764,7 +5764,7 @@ After a copy `x` and `y` can be independent objects (value semantics, the way no
##### Note ##### Note
Prefer copy semantics unless you are building a "smart pointer". Value semantics is the simplest to reason about and what the standard library facilities expect. Prefer copy semantics unless you are building a "smart pointer". Value semantics is the simplest to reason about and what the standard-library facilities expect.
##### Enforcement ##### Enforcement
@ -5939,7 +5939,7 @@ There is no know general way of avoiding a `if (this == &a) return *this;` test
##### Note ##### Note
The ISO standard guarantees only a "valid but unspecified" state for the standard library containers. Apparently this has not been a problem in about 10 years of experimental and production use. Please contact the editors if you find a counter example. The rule here is more caution and insists on complete safety. The ISO standard guarantees only a "valid but unspecified" state for the standard-library containers. Apparently this has not been a problem in about 10 years of experimental and production use. Please contact the editors if you find a counter example. The rule here is more caution and insists on complete safety.
##### Example ##### Example
@ -7833,7 +7833,7 @@ To find function objects and functions defined in a separate namespace to "custo
##### Example ##### Example
Consider `swap`. It is a general (standard library) function with a definition that will work for just about any type. Consider `swap`. It is a general (standard-library) function with a definition that will work for just about any type.
However, it is desirable to define specific `swap()`s for specific types. However, it is desirable to define specific `swap()`s for specific types.
For example, the general `swap()` will copy the elements of two `vector`s being swapped, whereas a good specific implementation will not copy elements at all. For example, the general `swap()` will copy the elements of two `vector`s being swapped, whereas a good specific implementation will not copy elements at all.
@ -12866,7 +12866,7 @@ Getting good performance measurements can be hard and require specialized tools.
##### Note ##### Note
A few simple microbenchmarks using Unix `time` or the standard library `<chrono>` can help dispel the most obvious myths. A few simple microbenchmarks using Unix `time` or the standard-library `<chrono>` can help dispel the most obvious myths.
If you can't measure your complete system accurately, at least try to measure a few of your key operations and algorithms. If you can't measure your complete system accurately, at least try to measure a few of your key operations and algorithms.
A profiler can help tell you which parts of your system are performance critical. A profiler can help tell you which parts of your system are performance critical.
Often, you will be surprised. Often, you will be surprised.
@ -14167,7 +14167,7 @@ Parallelism rule summary:
## <a name="SScp-mess"></a>CP.mess: Message passing ## <a name="SScp-mess"></a>CP.mess: Message passing
The standard-library facilities are quite low level, focused on the needs of close-to the hardware critical programming using `thread`s, `mutex`es, `atomic` types, etc. The standard-library facilities are quite low-level, focused on the needs of close-to the hardware critical programming using `thread`s, `mutex`es, `atomic` types, etc.
Most people shouldn't work at this level: it's error-prone and development is slow. Most people shouldn't work at this level: it's error-prone and development is slow.
If possible, use a higher level facility: messaging libraries, parallel algorithms, and vectorization. If possible, use a higher level facility: messaging libraries, parallel algorithms, and vectorization.
This section looks at passing messages so that a programmer doesn't have to do explicit synchronization. This section looks at passing messages so that a programmer doesn't have to do explicit synchronization.
@ -14845,7 +14845,7 @@ By declaring `compute` to be `noexcept`, we give the compiler and human readers
##### Note ##### Note
Many standard library functions are `noexcept` including all the standard library functions "inherited" from the C standard library. Many standard-library functions are `noexcept` including all the standard-library functions "inherited" from the C standard library.
##### Example ##### Example
@ -15046,7 +15046,7 @@ Every example we have seen of this is error-prone, specialized, and often buggy.
##### Note ##### Note
The standard library assumes that destructors, deallocation functions (e.g., `operator delete`), and `swap` do not throw. If they do, basic standard library invariants are broken. The standard library assumes that destructors, deallocation functions (e.g., `operator delete`), and `swap` do not throw. If they do, basic standard-library invariants are broken.
##### Note ##### Note
@ -16851,7 +16851,7 @@ This prints `T0` and `Bad`.
Now the `==` in `Bad` was designed to cause trouble, but would you have spotted the problem in real code? Now the `==` in `Bad` was designed to cause trouble, but would you have spotted the problem in real code?
The problem is that `v.size()` returns an `unsigned` integer so that a conversion is needed to call the local `==`; The problem is that `v.size()` returns an `unsigned` integer so that a conversion is needed to call the local `==`;
the `==` in `Bad` requires no conversions. the `==` in `Bad` requires no conversions.
Realistic types, such as the standard library iterators can be made to exhibit similar anti-social tendencies. Realistic types, such as the standard-library iterators can be made to exhibit similar anti-social tendencies.
##### Note ##### Note
@ -18600,7 +18600,7 @@ If code is using an unmodified standard library, then there are still workaround
##### Enforcement ##### Enforcement
* Issue a diagnostic for any call to a standard library function that is not bounds-checked. * Issue a diagnostic for any call to a standard-library function that is not bounds-checked.
??? insert link to a list of banned functions ??? insert link to a list of banned functions
This rule is part of the [bounds profile](#SS-bounds). This rule is part of the [bounds profile](#SS-bounds).
@ -19680,7 +19680,7 @@ Bounds safety profile summary:
[Pass pointers to single objects (only)](#Ri-array) and [Keep pointer arithmetic simple](#Res-simple). [Pass pointers to single objects (only)](#Ri-array) and [Keep pointer arithmetic simple](#Res-simple).
* <a href="Pro-bounds-decay"></a>Bounds.3: No array-to-pointer decay: * <a href="Pro-bounds-decay"></a>Bounds.3: No array-to-pointer decay:
[Pass pointers to single objects (only)](#Ri-array) and [Keep pointer arithmetic simple](#Res-simple). [Pass pointers to single objects (only)](#Ri-array) and [Keep pointer arithmetic simple](#Res-simple).
* <a href="Pro-bounds-stdlib"></a>Bounds.4: Don't use standard library functions and types that are not bounds-checked: * <a href="Pro-bounds-stdlib"></a>Bounds.4: Don't use standard-library functions and types that are not bounds-checked:
[Use the standard library in a type-safe manner](#Rsl-bounds). [Use the standard library in a type-safe manner](#Rsl-bounds).
##### Impact ##### Impact
@ -20831,7 +20831,7 @@ Consider the following advice and requirements found in the C++ Standard:
> If a destructor called during stack unwinding exits with an exception, terminate is called (15.5.1). So destructors should generally catch exceptions and not let them propagate out of the destructor. --[\[C++03\]](#C++03) §15.2(3) > If a destructor called during stack unwinding exits with an exception, terminate is called (15.5.1). So destructors should generally catch exceptions and not let them propagate out of the destructor. --[\[C++03\]](#C++03) §15.2(3)
> >
> No destructor operation defined in the C++ Standard Library (including the destructor of any type that is used to instantiate a standard library template) will throw an exception. --[\[C++03\]](#C++03) §17.4.4.8(3) > No destructor operation defined in the C++ Standard Library (including the destructor of any type that is used to instantiate a standard-library template) will throw an exception. --[\[C++03\]](#C++03) §17.4.4.8(3)
Deallocation functions, including specifically overloaded `operator delete` and `operator delete[]`, fall into the same category, because they too are used during cleanup in general, and during exception handling in particular, to back out of partial work that needs to be undone. Deallocation functions, including specifically overloaded `operator delete` and `operator delete[]`, fall into the same category, because they too are used during cleanup in general, and during exception handling in particular, to back out of partial work that needs to be undone.
Besides destructors and deallocation functions, common error-safety techniques rely also on `swap` operations never failing -- in this case, not because they are used to implement a guaranteed rollback, but because they are used to implement a guaranteed commit. For example, here is an idiomatic implementation of `operator=` for a type `T` that performs copy construction followed by a call to a no-fail `swap`: Besides destructors and deallocation functions, common error-safety techniques rely also on `swap` operations never failing -- in this case, not because they are used to implement a guaranteed rollback, but because they are used to implement a guaranteed commit. For example, here is an idiomatic implementation of `operator=` for a type `T` that performs copy construction followed by a call to a no-fail `swap`: