And the Five Winners for “C++ Core Guidelines: Best Practices for Modern C++”

Today, I want to present the five winners of the vouchers for my book “C++ Core Guidelines Explained: Best Practices for Modern C++”.



First, I have to adjust the number. Instead of five, I will give away seven vouchers. Why? Honestly, I could not decide. Additionally, I got more than 30 answers. Therefore, I added three vouchers. Here are the answers in the order I got the. You should already have the voucher.


Not surprisingly the first thing I had in mind were smart pointers, but that would be too evident. And I was also not sure if you mean language or library features. We used to have smart pointers before from boost, etc.
Keeping that in mind, to me, it’s the override specifier. It makes intentions so much clearer! With virtual you know exactly one thing, that very function can be overridden. But you have no idea whether it’s overriding something or not. Forgetting a const here, using another similar type there, and you have some issues that are very difficult to spot. The override specifier changed that and helped me to catch some subtle bugs in our codebase that I would have never found.



The most influential feature of C++ 17 for me has been structured bindings.
Structured bindings let me write and refactor flexible code in places like interacting with a std::pair returned from a function (multiple return) or iterating over a map or custom type.
As long as we choose descriptive variable & function names, structured bindings enable us to write concise but readable code using words of intent related to the domain we’re working in instead of only relying on type names.

I also think structured bindings help C++ be considered as a “modern” language, they’re a convenience that’s almost expected now if you look at how often the same feature is used in languages like Golang and JavaScript. Sure they’re different worlds, but I like to learn and take inspiration from anywhere I can and translate it into my own program design if it fits well.


The most influential feature for me is the introduction on “thread” support in C++11.
This is because of the reason that , it is very basic requirement for any good software project. Earlier we had to know and learn platform specific threads like “pthreads” in Linux, Win32 APIs on Windows etc. 
But with thread introduction in C++11 and concurrency support provided for it has made it cross-platform and also lead to advanced concepts like promise/future.


I mostly know C++11. I would write couples of words about lambda function or expression. It creates an anonymous function.
A lambda expression is a mechanism for specifying a function object. The primary use for lambda is to specify a simple action to be performed by some function. 
For instance, one can declare the argument [ ] (int x, int y) { return sin( x ) < sin( y ); } with the condition, x and y are between [0 pi]  – this is a “lambda function” or “lambda expression”, which specifies an operation that given two integer arguments x and y returns the result of comparing their sin values.  A lambda expression can as well access local variables in the scope in which it is used.


my “most influential feature” of the last decade in C++ was the std::shared_ptr (and also the std::unique_ptr). I could never “befriend” the auto_ptr, never used it – but the new kind of smart pointers became real quick my best buddies.

After working with Java and Android next to C++, the memory management with new and delete felt like being from the stone ages. With a lot of trouble on how, when and where to allocate and to free the memory. Plus how (not) to pass those pointers around in the code.


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.


    Especially using the smart pointers with RAII frees up a lot of cognitive load. I don’t need to think about the memory allocation, the compiler will do this for me. And releases the memory after the last (or only) reference falls out of scope.

    And they are still nice to use even though some of the code got more complex. Simple forward declarations of classes no longer work (the smart pointers need to do a “sizeof()”), and circular dependencies had to be solved in a different way. I do it in Java style with abstract classes emulating interfaces, so the class for the smart pointer is compiled as separate unit.


    this is a tough question, since there are so many improvements in the C++ language since the advent of C++11. So I thought what feature has altered the way I program C++ the most. The two main features I considered was “auto” and “smart pointers (unique_ptr, shared_ptr)” and I must say that smart pointers transformed my code definitely more than auto. Auto helps a lot but it is mainly syntactic sugar. In contrast smart pointers enable C++ programmers to use a different style of programming. The owner of objects can be clearly expressed also the distinction between single or exclusive ownership in contrast to shared ownership can be expressed with the use of unique_ptr and shared_ptr. The smart pointers also make programming idioms like RAII easier. Lastly smart pointers avoid several security pitfalls if applied correctly. It avoids dangling memory objects since the lifetime of objects is tied to a scope and exiting the scope automatically deletes the object.


    My vote for the most influential feature of C++11/14/17 goes to the specifier constexpr, introduced in C++ 11.

    According to cppreference ( “The constexpr specifier declares that it is possible to evaluate the value of the function or variable at compile time.”. Trivially, for example we can declare:

    constexpr auto meaning_of_life{ 42 };

    This quite innocuous feature allows you to declare variables that can be evaluated at compile time. Like its runtime counterpart const, it allows you to be clear about the meaning of a piece of code. In the best tradition of C++ it allows you to express your intention exactly (say what you mean and mean what you say).

    But it is not just limited to variables. constexpr can apply to functions that can be compiletime evaluated. For example, given the following arrangement:

    enum class MediaType
    using MediaTypeItem = std::pair<MediaType, std::string_view>;
    struct MediaTypeValues
        static constexpr std::array<MediaTypeItem, 3> values{
            {{MediaType::Book, "Book"sv},
             {MediaType::Music, "Music"sv},
             {MediaType::Video, "Video"sv}}};
    constexpr std::string_view GetString(MediaType in)
        for (const auto &v : MediaTypeValues::values)
            if (v.first == in)
                return v.second;
        return {};


    We can take advantage of constexpr to create a compiletime evaluated std::array to map enumerated values to their string counterparts. constexpr allows us to take code that was once evaluated at runtime and make it into compiletime evaluated code. And this is evaluated at compile time as shown below:


    The function GetString is evaluated at compiletime, as is displayed by Visual Studio’s IntelliSense.

    Of course, we’ve always had compiletime constructs (template metaprogramming uses compiletime evaluation extensively), but these have often been esoteric (computing factorials at compiletime for example). What makes constexpr so influential is that it opens the way to redesigning whole sections of a codebase from runtime to compiletime evaluated code. As constexpr permeates the STL, it encourages redesign and refactoring. Where once some code might have been runtime evaluated, now we can use constexpr to redesign it to be compiletime evaluated and hence more efficient.


    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, 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, Charles-Jianye Chen, and Keith Jeffery.

    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 
    My special thanks to Take Up Code
    My special thanks to SHAVEDYAKS


    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 *