From c5cecf1e886345afb62a3bdd056b82cfe9698774 Mon Sep 17 00:00:00 2001 From: Bjarne Stroustrup Date: Sat, 11 Feb 2017 12:25:05 -0500 Subject: [PATCH] new rule F.9; unused parameters Issue #808 --- CppCoreGuidelines.md | 54 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 51 insertions(+), 3 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index f478e0d..7157325 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -1,6 +1,6 @@ # C++ Core Guidelines -February 9, 2017 +February 11, 2017 Editors: @@ -2033,6 +2033,7 @@ Function definition rules: * [F.6: If your function may not throw, declare it `noexcept`](#Rf-noexcept) * [F.7: For general use, take `T*` or `T&` arguments rather than smart pointers](#Rf-smart) * [F.8: Prefer pure functions](#Rf-pure) +* [F.9: Unused parameters should be unnamed](#Rf-unused) Parameter passing expression rules: @@ -2394,7 +2395,7 @@ The C++ standard library does that implicitly for all functions in the C standar ##### Note -`constexpr` functions cannot throw, so you don't need to use `noexcept` for those. +`constexpr` functions can when evaluated at run time, so yu may need `noexcept` for some of those. ##### Example @@ -2520,6 +2521,25 @@ if not, this is not an issue. Not possible. +### F.9: Unused parameters should be unnamed + +##### Reason + +Readability. +Suppression of unused parameter warnings. + +##### Example + + X* find(map& m, const string& s, Hint); // once upon a time, a hint was used + +##### Note + +Allowing parameters to be unnamed was introduced in the early 1980 to address this problem. + +##### Enforcement + +Flag named unused parameters. + ## F.call: Parameter passing There are a variety of ways to pass parameters to a function and to return values. @@ -3721,11 +3741,15 @@ This rule becomes even better if C++ gets ["uniform function call"](http://www.o ##### Exception -`virtual` funtions must be members because of language rules, and not all `virtual` functions directly access data. +The language requires `virtual` funtions to be members, and not all `virtual` functions directly access data. In particular, members of an abstract class rarely do. Note [multimethods](https://parasol.tamu.edu/~yuriys/papers/OMM10.pdf). +##### Exception + +The language requires operators `=`, `()`, `[]`, and `->` to be members. + ###### Exception An overload set may have some members that do not directly access `private` data: @@ -17264,6 +17288,7 @@ Type safety profile summary: * [Type.4: Don't use C-style `(T)expression` casts that would perform a `static_cast` downcast, `const_cast`, or `reinterpret_cast`](#Pro-type-cstylecast) * [Type.5: Don't use a variable before it has been initialized](#Pro-type-init) * [Type.6: Always initialize a member variable](#Pro-type-memberinit) +* [Type.7: Don't use `T(expression)` for casting`](#Pro-fct-style-cast) ### Type.1: Don't use `reinterpret_cast`. @@ -17456,6 +17481,29 @@ Note that a C-style `(T)expression` cast means to perform the first of the follo Issue a diagnostic for any use of a C-style `(T)expression` cast that would invoke a `static_cast` downcast, `const_cast`, or `reinterpret_cast`. To fix: Use a `dynamic_cast`, `const`-correct declaration, or `variant`, respectively. +### Type.7: Don't use `T(expression)` for casting` + +##### Reason + +If `e` is of a built-in type, `T(e)` is equivalent to the error-prone `(T)e`. + +##### Example, bad + + int* p = f(x); + auto i = int(p); // Potential damaging cast; don't or use `reinterpret_cast` + + short s = short(i); // potentially narrowing; don't or use `narrow` or `narrow_cast` + +##### Note + +The {}-syntax makes the desire for construction explicit and doesn't allow narrowing + + f(Foo{bar}); + +##### Enforcement + +Flag `T(e)` if used for `e` of a built-in type. + ### Type.5: Don't use a variable before it has been initialized. [ES.20: Always initialize an object](#Res-always) is required.