Merge branch 'master' of https://github.com/isocpp/CppCoreGuidelines

CppCoreGuidelines.md

@@ -765,10 +765,13 @@ There are cases where checking early is dumb because you may not ever need the v
 
     class Jet {    // Physics says: e*e < x*x + y*y + z*z
 
-        float fx, fy, fz, fe;
+        float x;
+        float y;
+        float z;
+        float e;
     public:
         Jet(float x, float y, float z, float e)
-            :fx(x), fy(y), fz(z), fe(e)
+            :x(x), y(y), z(z), e(e)
         {
             // Should I check here that the values are physically meaningful?
         }
@@ -2239,8 +2242,8 @@ When copying is cheap, nothing beats the simplicity and safety of copying, and f
 
 For advanced uses (only), where you really need to optimize for rvalues passed to "input-only" parameters:
 
-* If the function is going to unconditionally move from the argument, take it by `&&`. See [F.21](#Rf-consume).
+* If the function is going to unconditionally move from the argument, take it by `&&`. See [F.18](#Rf-consume).
-* If the function is going to keep a copy of the argument, in addition to passing by `const&` add an overload that passes the parameter by `&&` and in the body `std::move`s it to its destination. Essentially this overloads a "consume"; see [F.21](#Rf-consume).
+* If the function is going to keep a copy of the argument, in addition to passing by `const&` add an overload that passes the parameter by `&&` and in the body `std::move`s it to its destination. Essentially this overloads a "consume"; see [F.18](#Rf-consume).
 * In special cases, such as multiple "input + copy" parameters, consider using perfect forwarding. See [F.19](#Rf-forward).
 
 ##### Example
@@ -2343,7 +2346,7 @@ Unique owner types that are move-only and cheap-to-move, such as `unique_ptr`, c
 
 If the object is to be passed onward to other code and not directly used by this function, we want to make this function agnostic to the argument `const`-ness and rvalue-ness.
 
-In that case, and only that case, make the parameter `TP&&` where `TP` is a template type parameter -- it both *ignores* and *preserves* `const`-ness and rvalue-ness. Therefore any code that uses a `T&&` is implicitly declaring that it itself doesn't care about the variable's `const`-ness and rvalue-ness (because it is ignored), but that intends to pass the value onward to other code that does care about `const`-ness and rvalue-ness (because it is preserved). When used as a parameter `TP&&` is safe because any temporary objects passed from the caller will live for the duration of the function call. A parameter of type `TP&&` should essentially always be passed onward via `std::forward` in the body of the function.
+In that case, and only that case, make the parameter `TP&&` where `TP` is a template type parameter -- it both *ignores* and *preserves* `const`-ness and rvalue-ness. Therefore any code that uses a `TP&&` is implicitly declaring that it itself doesn't care about the variable's `const`-ness and rvalue-ness (because it is ignored), but that intends to pass the value onward to other code that does care about `const`-ness and rvalue-ness (because it is preserved). When used as a parameter `TP&&` is safe because any temporary objects passed from the caller will live for the duration of the function call. A parameter of type `TP&&` should essentially always be passed onward via `std::forward` in the body of the function.
 
 ##### Example
 
@@ -2419,7 +2422,7 @@ And yes, C++ does have multiple return values, by convention of using a `tuple`,
     tuple<int, string> f(const string& input) // GOOD: self-documenting
     {
         // ...
-        return make_tuple(something(), status);
+        return make_tuple(status, something());
     }
 
 In fact, C++98's standard library already used this convenient feature, because a `pair` is like a two-element `tuple`.
@@ -2626,7 +2629,7 @@ Using `std::shared_ptr` is the standard way to represent shared ownership. That
     std::thread t2 {shade, args2, bottom_left, im};
     std::thread t3 {shade, args3, bottom_right, im};
 
-    // detach treads
+    // detach threads
     // last thread to finish deletes the image
 
 ##### Note