From ab91388efd0889027c99675a85b927d7399d132d Mon Sep 17 00:00:00 2001 From: Sergey Zubkov Date: Thu, 19 Mar 2020 14:34:50 -0400 Subject: [PATCH] fix mismatched anchors, closes #1569 (#1581) --- CppCoreGuidelines.md | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 30e423a..3548ffc 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -1823,7 +1823,7 @@ We don't consider "performance" a valid reason not to use exceptions. * Often, explicit error checking and handling consume as much time and space as exception handling. * Often, cleaner code yields better performance with exceptions (simplifying the tracing of paths through the program and their optimization). -* A good rule for performance critical code is to move checking outside the critical part of the code ([checking](#Rper-checking)). +* A good rule for performance critical code is to move checking outside the [critical](#Rper-critical) part of the code. * In the longer term, more regular code gets better optimized. * Always carefully [measure](#Rper-measure) before making performance claims. @@ -1982,7 +1982,7 @@ This `draw2()` passes the same amount of information to `draw()`, but makes the ##### Exception Use `zstring` and `czstring` to represent C-style, zero-terminated strings. -But when doing so, use `std::string_view` or `string_span` from the [GSL](#GSL) to prevent range errors. +But when doing so, use `std::string_view` or `string_span` from the [GSL](#S-gsl) to prevent range errors. ##### Enforcement @@ -12316,7 +12316,7 @@ This is a major part of the discussion of [C++'s model for type- and resource-sa * Use [unique_ptr](#Rf-unique_ptr) to avoid lifetime problems. * Use [shared_ptr](#Rf-shared_ptr) to avoid lifetime problems. * Use [references](#Rf-ptr-ref) when `nullptr` isn't a possibility. -* Use [not_null](#Rf-not_null) to catch unexpected `nullptr` early. +* Use [not_null](#Rf-nullptr) to catch unexpected `nullptr` early. * Use the [bounds profile](#SS-bounds) to avoid range errors. @@ -16536,8 +16536,8 @@ Concept definition rule summary: * [T.24: Use tag classes or traits to differentiate concepts that differ only in semantics](#Rt-tag) * [T.25: Avoid complementary constraints](#Rt-not) * [T.26: Prefer to define concepts in terms of use-patterns rather than simple syntax](#Rt-use) -* [T.30: Use concept negation (`!C`) sparingly to express a minor difference](#Rt-not) -* [T.31: Use concept disjunction (`C1 || C2`) sparingly to express alternatives](#Rt-or) +* [T.30: Use concept negation (`!C`) sparingly to express a minor difference](#Rt-???) +* [T.31: Use concept disjunction (`C1 || C2`) sparingly to express alternatives](#Rt-???) * ??? Template interface rule summary: @@ -16798,7 +16798,7 @@ See the reference to more specific rules. ## T.concepts: Concept rules Concepts is a facility for specifying requirements for template arguments. -It is an [ISO Technical Specification](#Ref-conceptsTS), but currently supported only by GCC. +It is an [ISO Technical Specification](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4553.pdf), but currently supported only by GCC. Concepts are, however, crucial in the thinking about generic programming and the basis of much work on future C++ libraries (standard and other). @@ -16885,7 +16885,7 @@ Flag template type arguments without concepts ##### Reason - "Standard" concepts (as provided by the [GSL](#S-GSL) and the [Ranges TS](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4569.pdf), and hopefully soon the ISO standard itself) + "Standard" concepts (as provided by the [GSL](#S-gsl) and the [Ranges TS](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4569.pdf), and hopefully soon the ISO standard itself) save us the work of thinking up our own concepts, are better thought out than we can manage to do in a hurry, and improve interoperability. ##### Note @@ -17682,7 +17682,7 @@ Because that's the best we can do without direct concept support. ##### Note -Beware of [complementary constraints](# T.25). +Beware of [complementary constraints](#Rt-not). Faking concept overloading using `enable_if` sometimes forces us to use that error-prone design technique. ##### Enforcement @@ -18031,7 +18031,7 @@ or a traditional traits template to be specialized on the user's type. If you intend to call your own helper function `helper(t)` with a value `t` that depends on a template type parameter, put it in a `::detail` namespace and qualify the call as `detail::helper(t);`. An unqualified call becomes a customization point where any function `helper` in the namespace of `t`'s type can be invoked; -this can cause problems like [unintentionally invoking unconstrained function templates](#Rt-unconstrained-adl). +this can cause problems like [unintentionally invoking unconstrained function templates](#Rt-visible). ##### Enforcement @@ -20654,13 +20654,13 @@ Type safety profile summary: * Type.3: Don't use `const_cast` to cast away `const` (i.e., at all): [Don't cast away const](#Res-casts-const). * Type.4: Don't use C-style `(T)expression` or functional `T(expression)` casts: -Prefer [construction](#Res-construct) or [named casts](#Res-cast-named). +Prefer [construction](#Res-construct) or [named casts](#Res-casts-named). * Type.5: Don't use a variable before it has been initialized: [always initialize](#Res-always). * Type.6: Always initialize a member variable: [always initialize](#Res-always), possibly using [default constructors](#Rc-default0) or -[default member initializers](#Rc-in-class-initializers). +[default member initializers](#Rc-in-class-initializer). * Type.7: Avoid naked union: [Use `variant` instead](#Ru-naked). * Type.8: Avoid varargs: @@ -22481,6 +22481,10 @@ Alternatively, we will decide that no change is needed and delete the entry. \[Meyers96]: S. Meyers. More Effective C++ (Addison-Wesley, 1996). * \[Meyers97]: S. Meyers. Effective C++ (2nd Edition) (Addison-Wesley, 1997). +* + \[Meyers01]: S. Meyers. Effective STL (Addison-Wesley, 2001). +* + \[Meyers05]: S. Meyers. Effective C++ (3rd Edition) (Addison-Wesley, 2005). * \[Meyers15]: S. Meyers. Effective Modern C++ (O'Reilly, 2015). *