declarationSmall

C++ Core Guidelines: More Rules for Declarations

In this post, I will finish the rules for declarations. The remaining rules for declarations are not especially sophisticated but important for high code quality.

 

declarationSmall

Let’s start. Here is the first overview before we dive into the details.

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.

ES.25: Declare an object const or constexpr unless you want to modify its value later on

Why should you use const or constexpr for your variable declaration if possible? I have a lot of good reasons:

 

Rainer D 6 P2 500x500Modernes C++ Mentoring

Be part of my mentoring programs:

  • "Fundamentals for C++ Professionals" (open)
  • "Design Patterns and Architectural Patterns with C++" (open)
  • "C++20: Get the Details" (open)
  • "Concurrency with Modern C++" (starts March 2024)
  • Do you want to stay informed: Subscribe.

     

    • You express your intention.
    • 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 initialized in a thread-safe way.
      • constexpr: The C++ runtime guarantees that the variable is initialized in a thread-safe way.

    ES.26: Don’t use a variable for two unrelated purposes

    Do you like such kind of code?

    void use()
    {
        int i;
        for (i = 0; i < 20; ++i) { /* ... */ }
        for (i = 0; i < 200; ++i) { /* ... */ } // bad: i recycled
    }
    

     

    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 a loop. 

    void use()
    {
        for (int i = 0; i < 20; ++i) { /* ... */ }
        for (int i = 0; i < 200; ++i) { /* ... */ } 
    }
    

     

    With C++17, you can declare your i just in an if or switch statement: C++17 – What’s new in the language?

    ES.27: Use std::array or stack_array for arrays on the stack

    10 years ago, I thought that creating a variable-length array on the stack is ISO C++. 

     

    const int n = 7;
    int m = 9;
    
    void f()
    {
        int a1[n];
        int a2[m];   // error: not ISO C++
        // ...
    }
    

     

    Wrong! 

    In the first case, you should use a std::array; in the second case, you can use a gsl::stack_array from the Guideline support library (GSL)

    const int n = 7;
    int m = 9;
    
    void f()
    {
        std::array<int, n> b1;
        gsl::stack_array<int> b2(m);
        // ...
    }
    

     

    Why should you use std::array instead of C-array or gsl::array instead of C-array?

    std::array 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: 

     

    void copy_n(const T* p, T* q, int n);   // copy from [p:p+n) to [q:q+n)
    

     

     Variable-length arrays such as int a2[m] are a security risk because you may execute arbitrary code or get stack exhaustion. 

    ES.28: Use lambdas for complex initialization, especially of const variables

    In 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. 

    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.

    Have a look here. The widget x in the following example should be const after its initialization.  It cannot be const because it will be changed a few times during its initialization.

    widget x;   // should be const, but:
    for (auto i = 2; i <= N; ++i) {             // this could be some
        x += some_obj.do_something_with(i);  // arbitrarily long code
    }                                        // needed to initialize x
    // from here, x should be const, but we can't say so in code in this style
    

     

    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.

     

    const widget x = [&]{
        widget val;                                // widget has a default constructor
        for (auto i = 2; i <= N; ++i) {            // this could be some
            val += some_obj.do_something_with(i);  // arbitrarily long code
        }                                          // needed to initialize x
        return val;
    }();
    

     

    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. 

    ES.30ES.31,  ES.32 and ES.33

    I 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.

    ES.34: Don’t define a (C-style) variadic function

    Right! Don’t define a (C-style) variadic function. Since C++11, we have variadic templates; since C++17, we have fold xpressions. This is all that 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 print has undefined behavior 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.cpp
    
    #include <iostream>
     
    void myPrintf(const char* format){                         // (1)
        std::cout << format;
    }
     
    template<typename T, typename... Targs>                    // (2)
    void myPrintf(const char* format, T value, Targs... Fargs) 
    {
        for ( ; *format != '\0'; format++ ) {
            if ( *format == '%' ) {
               std::cout << value;                             // (3)
               myPrintf(format+1, Fargs...);                   // (4)
               return;
            }
            std::cout << *format;
        }
    }
     
    int main(){
        myPrintf("% world% %\n","Hello",'!',123);            // Hello world! 123
    }
    

     

    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 exceed 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 handle format strings such as  %d, %f, or 5.5f.

    What’s next?

    There is a lot to write about expression. The C++ core guidelines have about 25 rules; therefore, my next post will deal with expression.

     

     

     

    Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, Philipp Lenk, Hobsbawm, and Charles-Jianye Chen.

    Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

    My special thanks to Embarcadero
    My special thanks to PVS-Studio
    My special thanks to Tipi.build 
    My special thanks to Take Up Code
    My special thanks to SHAVEDYAKS

    Seminars

    I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

    Standard Seminars (English/German)

    Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

    • C++ – The Core Language
    • C++ – The Standard Library
    • C++ – Compact
    • C++11 and C++14
    • Concurrency with Modern C++
    • Design Pattern and Architectural Pattern with C++
    • Embedded Programming with Modern C++
    • Generic Programming (Templates) with C++
    • Clean Code with Modern C++
    • C++20

    Online Seminars (German)

    Contact Me

    Modernes C++ Mentoring,

     

     

    0 replies

    Leave a Reply

    Want to join the discussion?
    Feel free to contribute!

    Leave a Reply

    Your email address will not be published. Required fields are marked *