![\"declarationSmall\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/01\/declarationSmall.png\")
<\/p>\nIn this post, I will finish the rules for declarations. The remaining rules for declarations are not especially sophisticated but important for high code quality.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Let’s start. Here is the first overview before we dive into the details.<\/p>\n
const<\/code> or constexpr<\/code> unless you want to modify its value later on<\/a><\/li>\n- ES.26: Don\u2019t use a variable for two unrelated purposes<\/a><\/li>\n
- ES.27: Use
std::array<\/code> or stack_array<\/code> for arrays on the stack<\/a><\/li>\n- ES.28: Use lambdas for complex initialization, especially of
const<\/code> variables<\/a><\/li>\n- ES.30: Don\u2019t use macros for program text manipulation<\/a><\/li>\n
- ES.31: Don\u2019t use macros for constants or \u201cfunctions\u201d<\/a><\/li>\n
- ES.32: Use
ALL_CAPS<\/code> for all macro names<\/a><\/li>\n- ES.33: If you must use macros, give them unique names<\/a><\/li>\n
- ES.34: Don\u2019t define a (C-style) variadic function<\/a><\/li>\n<\/ul>\n
In Python, there is an aphorism from the Zen of Python (Tim Peters): “Explicit is better than implicit”. This is a kind of meta-rule in Python for writing good code. This meta-rule holds, in particular, valid for the following two rules in the C++ core guidelines.<\/p>\n
ES.25: Declare an object const<\/code> or constexpr<\/code> unless you want to modify its value later on<\/a><\/h3>\nWhy should you use const<\/span> or constexpr<\/span> for your variable declaration if possible? I have a lot of good reasons:<\/p>\n\n- You express your intention.<\/li>\n
- The variable cannot be changed by accident.<\/li>\n
- const<\/span> or constexpr<\/span> variables are, by definition, thread-safe.\n
\n- const<\/span>: You have to guarantee that the variable is initialized in a thread-safe way.<\/li>\n
- constexpr<\/span>: The C++ runtime guarantees that the variable is initialized in a thread-safe way.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
ES.26: Don\u2019t use a variable for two unrelated purposes<\/a><\/h3>\nDo you like such kind of code?<\/p>\n
\nvoid<\/span> use<\/span>()\r\n{\r\n int<\/span> i;\r\n for<\/span> (i =<\/span> 0<\/span>; i <<\/span> 20<\/span>; ++<\/span>i) { \/* ... *\/<\/span> }\r\n for<\/span> (i =<\/span> 0<\/span>; i <<\/span> 200<\/span>; ++<\/span>i) { \/* ... *\/<\/span> } \/\/ bad: i recycled<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
I hope not. Put the declaration of i<\/span> into the for loop, and you are fine. i will be bound to the lifetime of the for a loop. <\/p>\n\nvoid<\/span> use<\/span>()\r\n{\r\n for<\/span> (int<\/span> i =<\/span> 0<\/span>; i <<\/span> 20<\/span>; ++<\/span>i) { \/* ... *\/<\/span> }\r\n for<\/span> (int<\/span> i =<\/span> 0<\/span>; i <<\/span> 200<\/span>; ++<\/span>i) { \/* ... *\/<\/span> } \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
With C++17, you can declare your i<\/span> just in an if<\/span> or switch<\/span> statement: C++17 – What’s new in the language?<\/a><\/p>\nES.27: Use std::array<\/code> or stack_array<\/code> for arrays on the stack<\/a><\/h3>\n10 years ago, I thought that creating a variable-length array on the stack is ISO C++. <\/p>\n
<\/p>\n
\nconst<\/span> int<\/span> n =<\/span> 7<\/span>;\r\nint<\/span> m =<\/span> 9<\/span>;\r\n\r\nvoid<\/span> f<\/span>()\r\n{\r\n int<\/span> a1[n];\r\n int<\/span> a2[m]; \/\/ error: not ISO C++<\/span>\r\n \/\/ ...<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Wrong! <\/p>\n
In the first case, you should use a std::array<\/span>; in the second case, you can use a gsl::stack_array<\/span> from the Guideline support library (GSL)<\/a>. <\/p>\n\nconst<\/span> int<\/span> n =<\/span> 7<\/span>;\r\nint<\/span> m =<\/span> 9<\/span>;\r\n\r\nvoid<\/span> f<\/span>()\r\n{\r\n std::<\/span>array<<\/span>int<\/span>, n><\/span> b1;\r\n gsl::<\/span>stack_array<<\/span>int<\/span>><\/span> b2(m);\r\n \/\/ ...<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Why should you use std::array<\/span> instead of C-array or gsl::array<\/span> instead of C-array?<\/p>\nstd::array<\/span> knows its length in contrast to the C-array and will not decay to a pointer as a function parameter. How easy is it to use the following function for copying arrays with the wrong length n: <\/p>\n <\/p>\n
\nvoid<\/span> copy_n<\/span>(const<\/span> T*<\/span> p, T*<\/span> q, int<\/span> n); \/\/ copy from [p:p+n) to [q:q+n)<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n
Variable-length arrays such as int a2[m]<\/span> are a security risk because you may execute arbitrary code or get stack exhaustion. <\/p>\nES.28: Use lambdas for complex initialization, especially of const<\/code> variables<\/a><\/h3>\nIn my seminars, I sometimes hear the question: Why should I invoke a lambda function just in place? This rule answers. You can put complex initialization in it. This in-place invocation is very valuable if your variable should become const. <\/p>\n
If you don’t want to modify your variable after the initialization, make it const according to the previous rule R.25. Fine. But sometimes, the variable’s initialization consists of more steps; therefore, you can make it not const.<\/p>\n
Have a look here. The widget x<\/span> in the following example should be const<\/span> after its initialization. It cannot be const<\/span> because it will be changed a few times during its initialization.<\/p>\n\nwidget x; \/\/ should be const, but:<\/span>\r\nfor<\/span> (auto<\/span> i =<\/span> 2<\/span>; i <=<\/span> N; ++<\/span>i) { \/\/ this could be some<\/span>\r\n x +=<\/span> some_obj.do_something_with(i); \/\/ arbitrarily long code<\/span>\r\n} \/\/ needed to initialize x<\/span>\r\n\/\/ from here, x should be const, but we can't say so in code in this style<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n
Now, a lambda function comes to our rescue. Put the initialization stuff into a lambda function, capture the environment by reference, and initialize your const variable with the in-place invoked lambda function.<\/p>\n
<\/p>\n
\nconst<\/span> widget x =<\/span> [&<\/span>]{\r\n widget val; \/\/ widget has a default constructor<\/span>\r\n for<\/span> (auto<\/span> i =<\/span> 2<\/span>; i <=<\/span> N; ++<\/span>i) { \/\/ this could be some<\/span>\r\n val +=<\/span> some_obj.do_something_with(i); \/\/ arbitrarily long code<\/span>\r\n } \/\/ needed to initialize x<\/span>\r\n return<\/span> val;\r\n}();\r\n<\/pre>\n<\/div>\n <\/p>\n
Admittedly, invoking a lambda function just in place looks strange, but I like it from the conceptual view. You put the whole initialization stuff just in a function body. <\/p>\n
ES.30<\/a>, ES.31, <\/a>ES.32<\/a> and ES.33<\/a><\/h3>\nI will only paraphrase the following four rules to macros. Don’t use macros for program test manipulation or constants and functions. If you have to use them, use unique names with ALL_CAPS.<\/p>\n
ES.34: Don\u2019t define a (C-style) variadic function<\/a><\/h3>\nRight! Don’t define a (C-style) variadic function. Since C++11, we have variadic templates;<\/span> since C++17, we have fold xpressions<\/a>. This is all that we need. <\/p>\nYou probably quite often used the (C-style) variadic function: printf. printf<\/span> accepts a format string and arbitrary numbers of arguments and displays its arguments respectively. A call of print has undefined behavior if you don’t use the correct format specifiers or the number of your arguments isn’t correct. <\/p>\n