This post is about template interfaces due to the C++ core guidelines: “…a critical concept”, because a template interface is “a contract between a user and an implementer – and should be carefully designed.”.
Here are the rules for today:
- T.41: Require only essential properties in a template’s concepts
- T.42: Use template aliases to simplify notation and hide implementation details
- T.43: Prefer
typedeffor defining aliases
- T.44: Use function templates to deduce class template argument types (where feasible)
Let me start with the first rule T.41:
What does it mean to specify only the essential properties? The guidelines provide an example of a sort algorithm that has debug support.
One question remains: What is the issue if you specify non-essential properties? This means that your concepts are firmly bound to the implementation. The result may be that a slight change in the implementation changes your concepts. In the end, your interface becomes quite unstable.
Since C++11, we have template aliases. A template alias is a name that refers to a family of types. Using them makes your code more readable and helps you to get rid of type traits. My previous post C++ Core Guidelines: Definition of Concepts, the Second, provides more information to type traits.
Let’s see what the guidelines mean by readability. The first example uses type traits:
Here is the corresponding case with template aliases.
Readability is also the argument that holds for the next rule
There are two arguments from the readability perspective to prefer using over typedef. First, using comes when used. Second, using it feels quite similar to auto. Additionally, using can easily be used for template aliases.
The first two lines define a pointer to a function (PFI and PFI2) that takes an int and returns an int. In the first case, typedef is used, and in the second line using. The last two lines define a function template (PFT2) which takes a type parameter T and returns an int. Line (1) is not valid.
The primary reason that we have too many make_ functions, such as std::make_tuple or std::make_unique is that a function template can deduce its template arguments from its function arguments. During this process, the compiler applies a few simple conversions, such as removing the outermost const/volatile qualifier and decaying C-arrays and functions to a pointer to the first element of the C-array or a pointer to the function.
This automatic template argument deduction makes our life as a programmer much more straightforward.
Instead of typing
you use the factory function std::make_tuple.
Sadly, automatic template type deduction is in C++ only available for function templates. Why? Constructors of class templates are a particular static function. Right! With C++17, the compiler can deduce its template arguments from its constructor arguments. Here is the way to define myTuple in C++17.
A noticeable effect of this C++17 feature is that most of the make_ functions become obsolete with C++17.
To know the details about class template argument deduction, including the argument deduction guide, read the post Modern C++ Features – Class Template Argument Deduction from Arne Mertz.
Teachability of C++
I have to admit; I like this C++17 feature. As a C++ trainer, my job is it to explain this difficult stuff. The more symmetric C++ becomes, the easier for me to speak about general ideas. Now I can say: “A template can automatically deduce its template arguments from its function arguments.”. In the past, I had to say this works only for function templates.
Here is a simple example:
The usage of the function template showMe or the class template ShowMe feels the same. From the user’s perspective, you don’t know you use a template.
With a current GCC 8.2, the program compiles and runs.
To be more specific, template argument deduction should work since GCC 7, Clang 5, and MSVC 19.14. cppreference.com gives you the details of the compiler support.
Do you know what a Regular or SemiRegular type is? If not, the next post to template interfaces is just the right one for you. Rule T.46 states: “Require template arguments to be at least Regular or SemiRegular.”.
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, Matthieu Bolt, 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, and Marco Parri Empoli.
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|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
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++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,