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.
Sandor
Tom
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.
Akash
Farés
Michael
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.
Modernes C++ Mentoring
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.
Tobias
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.
Adam
My vote for the most influential feature of C++11/14/17 goes to the specifier constexpr
, introduced in C++ 11.
According to cppreference (https://en.cppreference.com/w/cpp/language/constexpr) “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 compile–time evaluated. For example, given the following arrangement:
enum class MediaType { Unknown, Music, Video, Book }; 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 compile–time 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 compile–time evaluated code. And this is evaluated at compile time as shown below:
The function GetString
is evaluated at compile–time, as is displayed by Visual Studio’s IntelliSense.
Of course, we’ve always had compile–time constructs (template metaprogramming uses compile–time evaluation extensively), but these have often been esoteric (computing factorials at compile– time for example). What makes constexpr
so influential is that it opens the way to redesigning whole sections of a codebase from runtime to compile–time 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 compile–time 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, 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, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.
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 |
Modernes C++ GmbH
Modernes C++ Mentoring (English)
Rainer Grimm
Yalovastraße 20
72108 Rottenburg
Mail: schulung@ModernesCpp.de
Mentoring: www.ModernesCpp.org
Modernes C++ Mentoring,
Leave a Reply
Want to join the discussion?Feel free to contribute!