From 104d2327d56dc294eaeaa30179a7054ba0565acc Mon Sep 17 00:00:00 2001 From: Thibault Kruse Date: Sun, 27 Sep 2015 19:30:07 +0200 Subject: [PATCH 1/5] fix markdown style --- CppCoreGuidelines.md | 36 +++++++++++++++++------------------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 32d2bbb..ec5f90f 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -4142,7 +4142,7 @@ Consider: -### C.63: Make move assignment non-`virtual`, take the parameter by `&&`, and return by non-`const `&` +### C.63: Make move assignment non-`virtual`, take the parameter by `&&`, and return by non-`const &` **Reason**: It is simple and efficient. @@ -4584,7 +4584,7 @@ Of course there are way of making `==` work in a hierarchy, but the naive approa **Example**: ??? - + **Enforcement**: ??? @@ -10848,8 +10848,6 @@ Profiles summary: * [Pro.bounds: Bounds safety](#SS-bounds) * [Pro.lifetime: Lifetime safety](#SS-lifetime) - - ## Type safety profile @@ -10859,11 +10857,11 @@ For the purposes of this section, type-safety is defined to be the property that The following are under consideration but not yet in the rules below, and may be better in other profiles: - - narrowing arithmetic promotions/conversions (likely part of a separate safe-arithmetic profile) - - arithmetic cast from negative floating point to unsigned integral type (ditto) - - selected undefined behavior: ??? this is a big bucket, start with Gaby's UB list - - selected unspecified behavior: ??? would this really be about safety, or more a portability concern? - - constness violations? if we rely on it for safety +* narrowing arithmetic promotions/conversions (likely part of a separate safe-arithmetic profile) +* arithmetic cast from negative floating point to unsigned integral type (ditto) +* selected undefined behavior: ??? this is a big bucket, start with Gaby's UB list +* selected unspecified behavior: ??? would this really be about safety, or more a portability concern? +* constness violations? if we rely on it for safety An implementation of this profile shall recognize the following patterns in source code as non-conforming and issue a diagnostic. @@ -11856,10 +11854,10 @@ If the class definition and the constructor body are in separate files, the long If your design wants virtual dispatch into a derived class from a base class constructor or destructor for functions like `f` and `g`, you need other techniques, such as a post-constructor -- a separate member function the caller must invoke to complete initialization, which can safely call `f` and `g` because in member functions virtual calls behave normally. Some techniques for this are shown in the References. Here's a non-exhaustive list of options: - * *Pass the buck:* Just document that user code must call the post-initialization function right after constructing an object. - * *Post-initialize lazily:* Do it during the first call of a member function. A Boolean flag in the base class tells whether or not post-construction has taken place yet. - * *Use virtual base class semantics:* Language rules dictate that the constructor most-derived class decides which base constructor will be invoked; you can use that to your advantage. (See [[Taligent94]](#Taligent94).) - * *Use a factory function:* This way, you can easily force a mandatory invocation of a post-constructor function. +* *Pass the buck:* Just document that user code must call the post-initialization function right after constructing an object. +* *Post-initialize lazily:* Do it during the first call of a member function. A Boolean flag in the base class tells whether or not post-construction has taken place yet. +* *Use virtual base class semantics:* Language rules dictate that the constructor most-derived class decides which base constructor will be invoked; you can use that to your advantage. (See [[Taligent94]](#Taligent94).) +* *Use a factory function:* This way, you can easily force a mandatory invocation of a post-constructor function. Here is an example of the last option: @@ -11913,7 +11911,7 @@ In summary, no post-construction technique is perfect. The worst techniques dodg Should destruction behave virtually? That is, should destruction through a pointer to a `base` class should be allowed? If yes, then `base`'s destructor must be public in order to be callable, and virtual otherwise calling it results in undefined behavior. Otherwise, it should be protected so that only derived classes can invoke it in their own destructors, and nonvirtual since it doesn't need to behave virtually virtual. **Example**: The common case for a base class is that it's intended to have publicly derived classes, and so calling code is just about sure to use something like a `shared_ptr`: - + ``` class base { public: @@ -12000,7 +11998,7 @@ public: }; ``` -* 1. `nefarious` objects are hard to use safely even as local variables: +1. `nefarious` objects are hard to use safely even as local variables: ``` void test(string& s) { @@ -12010,7 +12008,7 @@ void test(string& s) { ``` Here, copying `s` could throw, and if that throws and if `n`'s destructor then also throws, the program will exit via `std::terminate` because two exceptions can't be propagated simultaneously. -* 2. Classes with `nefarious` members or bases are also hard to use safely, because their destructors must invoke `nefarious`' destructor, and are similarly poisoned by its poor behavior: +2. Classes with `nefarious` members or bases are also hard to use safely, because their destructors must invoke `nefarious`' destructor, and are similarly poisoned by its poor behavior: ``` class innocent_bystander { @@ -12026,13 +12024,13 @@ void test(string& s) { Here, if constructing `copy2` throws, we have the same problem because `i`'s destructor now also can throw, and if so we'll invoke `std::terminate`. -* 3. You can't reliably create global or static `nefarious` objects either: +3. You can't reliably create global or static `nefarious` objects either: ``` static nefarious n; // oops, any destructor exception can't be caught ``` -* 4. You can't reliably create arrays of `nefarious`: +4. You can't reliably create arrays of `nefarious`: ``` void test() { @@ -12041,7 +12039,7 @@ void test() { The behavior of arrays is undefined in the presence of destructors that throw because there is no reasonable rollback behavior that could ever be devised. Just think: What code can the compiler generate for constructing an `arr` where, if the fourth object's constructor throws, the code has to give up and in its cleanup mode tries to call the destructors of the already-constructed objects... and one or more of those destructors throws? There is no satisfactory answer. -* 5. You can't use `Nefarious` objects in standard containers: +5. You can't use `Nefarious` objects in standard containers: ``` std::vector vec(10); // this is line can std::terminate() From 411a5749e457c6479302396fd890e7ee6a16b91c Mon Sep 17 00:00:00 2001 From: Thibault Kruse Date: Sat, 26 Sep 2015 15:04:27 +0200 Subject: [PATCH 2/5] typos --- CppCoreGuidelines.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index ec5f90f..7f79adb 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -11293,7 +11293,7 @@ These functions all have bounds-safe overloads that take `array_view`. Standard * Impact on the standard library will require close coordination with WG21, if only to ensure compatibility even if never standardized. * We are considering specifying bounds-safe overloads for stdlib (especially C stdlib) functions like `memcmp` and shipping them in the GSL. -* For existing stdlib functions and types like `vector` that are not fully bounds-checked, the goal is for these features to be bounds-checked when called from code with the bounds profile on, and unchecked when called from legacy code, possibly using constracts (concurrently being proposed by several WG21 members). +* For existing stdlib functions and types like `vector` that are not fully bounds-checked, the goal is for these features to be bounds-checked when called from code with the bounds profile on, and unchecked when called from legacy code, possibly using contracts (concurrently being proposed by several WG21 members). ## Lifetime safety profile @@ -11905,7 +11905,6 @@ In summary, no post-construction technique is perfect. The worst techniques dodg - ### Discussion: Make base class destructors public and virtual, or protected and nonvirtual Should destruction behave virtually? That is, should destruction through a pointer to a `base` class should be allowed? If yes, then `base`'s destructor must be public in order to be callable, and virtual otherwise calling it results in undefined behavior. Otherwise, it should be protected so that only derived classes can invoke it in their own destructors, and nonvirtual since it doesn't need to behave virtually virtual. @@ -11977,13 +11976,13 @@ 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 -### Dicussion: Usage of noexecpt +### Discussion: Usage of noexecpt ??? -### Dicussion: Destructors, deallocation, and swap must never fail +### Discussion: Destructors, deallocation, and swap must never fail Never allow an error to be reported from a destructor, a resource deallocation function (e.g., `operator delete`), or a `swap` function using `throw`. It is nearly impossible to write useful code if these operations can fail, and even if something does go wrong it nearly never makes any sense to retry. Specifically, types whose destructors may throw an exception are flatly forbidden from use with the C++ standard library. Most destructors are now implicitly `noexcept` by default. @@ -12259,7 +12258,7 @@ The use of `array_view` and `string_view` should help a lot (they are not resour string* p = bad(); vector xx = {7, 8, 9}; string x = *p; // undefined behavior: x may not be 1 - *p = "Evil!"; // undefined behavior: we don't know what (if anytihng) is allocated a location p + *p = "Evil!"; // undefined behavior: we don't know what (if anything) is allocated a location p } The `string`s of `v` are destroyed upon exit from `bad()` and so is `v` itself. This the returned pointer points to unallocated memory on the free store. This memory (pointed into by `p`) may have been reallocated by the time `*p` is executed. There may be no `string` to read and a write through `p` could easily corrupt objects of unrelated types. From c2266bd8e4b6995f2bc1634658fc0c85b0fdc9e7 Mon Sep 17 00:00:00 2001 From: Thibault Kruse Date: Sat, 26 Sep 2015 15:35:54 +0200 Subject: [PATCH 3/5] fix bad indentation, causes bullet list to become code block --- CppCoreGuidelines.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 7f79adb..f553677 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -2347,7 +2347,7 @@ rather than using the generic `tuple`. **Enforcement**: - * Output parameters should be replaced by return values. +* Output parameters should be replaced by return values. An output parameter is one that the function writes to, invokes a non-`const` member function, or passes on as a non-`const`. @@ -2556,7 +2556,7 @@ For passthrough functions that pass in parameters (by ordinary reference or by p **Enforcement**: - * Warn on use of a named non-generic lambda (e.g., `auto x = [](int i){ /*...*/; };`) that captures nothing and appears at global scope. Write an ordinary function instead. +* Warn on use of a named non-generic lambda (e.g., `auto x = [](int i){ /*...*/; };`) that captures nothing and appears at global scope. Write an ordinary function instead. From 452f587a4de44c8b469dd1aa6286b3b85561545d Mon Sep 17 00:00:00 2001 From: Thibault Kruse Date: Sat, 26 Sep 2015 15:22:55 +0200 Subject: [PATCH 4/5] bad indentation, mark missing example with ??? --- CppCoreGuidelines.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index f553677..1bb8bc2 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -645,7 +645,8 @@ This design carries the number of elements along as an integral part of an objec **Example**: - show how possible checks are avoided by interfaces that pass polymorphic base classes around, when they actually know what they need? + * ??? + * show how possible checks are avoided by interfaces that pass polymorphic base classes around, when they actually know what they need? Or strings as "free-style" options **Enforcement**: From 78b66f4eaea9461544e3e0df4718dd7d03b1ebb8 Mon Sep 17 00:00:00 2001 From: Thibault Kruse Date: Sat, 26 Sep 2015 15:32:31 +0200 Subject: [PATCH 5/5] Obsolete question marks --- CppCoreGuidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 1bb8bc2..658321a 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -9797,7 +9797,7 @@ Similar for `Vector::sort()`. Unless those two functions are called that's code bloat. Imagine what this would do to a class hierarchy with dozens of member functions and dozens of derived classes with many instantiations. -**Note**: In many cases you can provide a stable interface by not parameterizing a base; see [???](#Rt-abi). +**Note**: In many cases you can provide a stable interface by not parameterizing a base; see [Rule](#Rt-abi). **Enforcement**: