Let's start. Here is the first overview before we dive into the details.
In Python, there is the aphorism from the Zen of Python (Tim Peters): "Explicit is better than implicit". This is a kind of a meta-rule in Python for writing good code. This meta-rule holds, in particular, true for the next two rules in the C++ core guidelines.
The variable cannot be changed by accident.
const or constexpr variables are by definition thread-safe.
const: You have to guarantee that the variable is initialised in a thread-safe way.
constexpr: The C++ runtime guarantees, that the variable is initialised in a thread-safe way.
Do you like such kind of code?
I hope not. Put the declaration of i into the for loop and you are fine. i will be bound to the lifetime of the for loop.
With C++17, you can declare your i just in an if or switch statement: C++17 - What's new in the language?
10 years ago, I thought that creating a variable length array on the stack is ISO C++.
In the first case, you should use an std::array and in the second case you can use a gsl::stack_array from the Guideline support library (GSL).
Why should you use std::array instead of C-array or gsl::array instead of C-array?
Variable length arrays such as int a2[m] are a security risk, because you may execute arbitrary code or get stack exhaustion.
I sometimes hear the question in my seminars: Why should I invoke a lambda function just in place? This rule gives an answer. You can put complex initialisation in it. This in place invocation is very valuable, if you variable should become const.
If you don't want to modify your variable after the initialisation, you should make it const according to the previous rule R.25. Fine. But sometimes the initialisation of the variable consist of more steps; therefore, you can make it not const.
Have a look here. The widget x in the following example should be const after its initialisation. It cannot be const because it will be changed a few times during its initialisation.
Now, a lambda function comes to our rescue. Put the initialisation stuff into a lambda function, capture the environment by reference, and initialise your const variable with the in-place invoked lambda function.
Admittedly, it looks a little bit strange to invoke a lambda function just in place, but from the conceptional view, I like it. You put the whole initialisation stuff just in a function body.
I will only paraphrase the next four rule to macros. Don't use macros for program test manipulation or for constants and functions. If you have to use them use unique names with ALL_CAPS.
Right! Don't define a (C-style) variadic function. Since C++11 we have variadic templates and since C++17 we have fold expressions. This all what we need.
You probably quite often used the (C-style) variadic function: printf. printf accepts a format string and arbitrary numbers of arguments and displays its arguments respectively. A call of printf has undefined behaviour if you don't use the correct format specifiers or the number of your arguments isn't correct.
By using variadic templates you can implement a type-safe printf function. Here is the simplified version of printf based on cppreference.com.
myPrintf can accept an arbitrary number of arguments. If arbitrary means 0, the first overload (1) is used. If arbitrary means more than 0, the second overload (2) is used. The function template (2) is quite interesting. It can accept an arbitrary number of arguments but the number must greater than 0. The first argument will be bound to value and written to std::cout (3). The rest of the arguments will be used in (4) to make a recursive call. This recursive call will create another function template myPrintf accepting one argument less. This recursion will go to zero. In this case, the function myPrintf (1) as boundary condition kicks in.
myPrintf is type-safe because all output will be handled by std::cout. This simplified implementation cannot deal with format strings such as %d, %f or 5.5f.
There is a lot to write about expression. The C++ core guidelines has about 25 rules for them; therefore, my next post will deal with expression.
Thanks a lot to my Patreon Supporters: Eric Pederson, Paul Baxter, Carlos Gomes Martinho, and SAI RAGHAVENDRA PRASAD POOSA.