{"id":5948,"date":"2020-07-24T08:27:34","date_gmt":"2020-07-24T08:27:34","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/template-improvements-with-c-20\/"},"modified":"2020-07-24T08:27:34","modified_gmt":"2020-07-24T08:27:34","slug":"template-improvements-with-c-20","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/template-improvements-with-c-20\/","title":{"rendered":"Various Template Improvements with C++20"},"content":{"rendered":"

Admittedly, I present in this post a few minor improvements to templates and C++20 in general. Although these improvements may not seem so impressive to you, they make C++20 more consistent and less error-prone when you program generic.<\/p>\n

<\/p>\n

 \"TimelineCpp20CoreLanguage\"<\/p>\n

Today’s post is about conditionally explicit constructors and new non-type template parameters.<\/p>\n

Conditionally Explicit Constructors<\/h2>\n

Sometimes, you want to have a class that should has constructors accepting various types. For example, you have a class VariantWrapper<\/span> which holds a std::variant<\/span> accepting different types.<\/p>\n

<\/p>\n

\n
class<\/span> VariantWrapper<\/span> {\r\n\r\n    std::<\/span>variant<<\/span>bool<\/span>, char<\/span>, int<\/span>, double<\/span>, float<\/span>, std::<\/span>string><\/span> myVariant;\r\n\r\n};\r\n<\/pre>\n<\/div>\n
 <\/p>\n
To initialize the myVariant with bool, char, int, double, float,<\/span> or std::string, <\/span>the class VariantWrapper<\/span> needs constructors for each listed type. Laziness is a virtue – at least for programmers – , therefore, you decide to make the constructor generic. <\/p>\n
<\/span>The class Implicit<\/span> exemplifies a generic constructor.<\/p>\n
<\/span><\/p>\n
<\/p>\n
\n
\/\/ explicitBool.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n#include <type_traits><\/span>\r\n\r\nstruct<\/span> Implicit {\r\n    template<\/span> <<\/span>typename<\/span> T>        \/\/ (1)<\/span><\/span>\r\n    Implicit(T t) {\r\n        std::<\/span>cout <<<\/span> t <<<\/span> std::<\/span>endl;\r\n    }\r\n};\r\n\r\nstruct<\/span> Explicit {\r\n    template<\/span> <<\/span>typename<\/span> T><\/span>\r\n    explicit<\/span> Explicit(T t) {    \/\/ (2)<\/span><\/span>\r\n        std::<\/span>cout <<<\/span> t <<<\/span> std::<\/span>endl;\r\n    }\r\n};\r\n\r\nint<\/span> main<\/span>() {\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \r\n    Implicit imp1 =<\/span> \"implicit\"<\/span>;\r\n    Implicit imp2(\"explicit\"<\/span>);\r\n    Implicit imp3 =<\/span> 1998<\/span>;\r\n    Implicit imp4(1998<\/span>);\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \r\n    \/\/ Explicit exp1 = \"implicit\";  \/\/ (3)<\/span>\r\n    Explicit exp2{\"explicit\"<\/span>};      \/\/ (4)<\/span>\r\n    \/\/ Explicit exp3 = 2011;        \/\/ (3)<\/span>\r\n    Explicit exp4{2011<\/span>};            \/\/ (4)<\/span>\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;  \r\n\r\n} \r\n<\/pre>\n<\/div>\n
 <\/p>\n
Now, you have an issue. A generic constructor (1) is a catch-all constructor because you can invoke them with any type. The constructor is way too greedy.  By putting an explicit<\/span> in front of the constructor (2). the constructor becomes explicit. This means that implicit conversions (3) are not valid anymore. Only explicit calls (4) are valid.<\/p>\n
Thanks to Clang 10, here is the output of the program:<\/p>\n
\"explicitBool\"<\/p>\n
This is not the and of the story. Maybe, you have a type MyBool<\/span> that should only support the implicit conversion from bool, <\/span>but no other implicit conversion.<\/span> In this case, explicit can be used conditionally.<\/p>\n
<\/p>\n
\n
\/\/ myBool.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <type_traits><\/span>\r\n#include <typeinfo><\/span>\r\n\r\nstruct<\/span> MyBool {\r\n    template<\/span> <<\/span>typename<\/span> T><\/span>\r\n    explicit<\/span>(!<\/span>std::<\/span>is_same<<\/span>T, bool<\/span>>::<\/span>value) MyBool(T t) {  \/\/ (1)<\/span>\r\n        std::<\/span>cout <<<\/span> typeid<\/span>(t).name() <<<\/span> std::<\/span>endl;\r\n    }\r\n};\r\n\r\nvoid<\/span> needBool<\/span>(MyBool b){ }                                 \/\/ (2)<\/span>\r\n\r\nint<\/span> main<\/span>() {\r\n\r\n    MyBool myBool1(true<\/span>);                              \r\n    MyBool myBool2 =<\/span> false<\/span>;                                \/\/ (3)<\/span>\r\n    \r\n    needBool(myBool1);\r\n    needBool(true<\/span>);                                        \/\/ (4)<\/span>\r\n    \/\/ needBool(5);<\/span>\r\n    \/\/ needBool(\"true\");<\/span>\r\n    \r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The explicit(!std::is_same<T,  bool>::value)<\/span> expression guarantees that MyBool<\/span> can only be implicitly created from a bool <\/span>value. The function std::is_same is<\/span> a compile-time predicate from the type_traits library<\/a>. Compile-time predicate means std::is_same<\/span> is evaluated at compile-time and returns a boolean. Consequently, the implicit conversion from bool<\/span> in (3) and (4) is possible, but not the commented-out conversions from int<\/span> and a C-string.<\/p>\n
You are right when you argue that a conditionally explicit constructor would be possible with SFINAE<\/a>. But honestly, I wouldn’t say I like the corresponding SFINAE using a constructor, because it would take me a few lines to explain it. Additionally, I only get it right after the third try.<\/p>\n
<\/p>\n
\n
template<\/span> <<\/span>typename<\/span> T, std::<\/span>enable_if_t<\/span><<\/span>std::<\/span>is_same_v<<\/span>std::<\/span>decay_t<\/span><<\/span>T><\/span>, bool<\/span>><\/span>, bool<\/span>><\/span> =<\/span> true<\/span>><\/span>\r\nMyBool(T&&<\/span> t) {\r\n    std::<\/span>cout <<<\/span> typeid<\/span>(t).name() <<<\/span> std::<\/span>endl;\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
I should add a few explaining words. std::enable_if <\/span>is a convenient way to use SFINAE. SFINAE stands for S<\/strong>ubstitution F<\/strong>ailure I<\/strong>s N<\/strong>ot A<\/strong>n E<\/strong>rror and applies during overload resolution of a function template. When substituting the template parameter fails, the specialization is discarded from the overload set but causes no compiler error. This exactly happens in this concrete case. The specialization is discarded if std::is_same_v<std::decay_t<T>, bool><\/span> evaluates to false. std::decay<T><\/span><\/a> applies conversions to T<\/span>, such as removing const<\/span>, volatile<\/span> or a reference from T. std::decay_t<T><\/span> is a convenient syntax for std::decay<T>::type. <\/span>The same holds for std::is_same_v<T, bool><\/span>, which is short for std::is_same<T, bool>::value. <\/span><\/p>\n
As my German reader pre alpha pointed out: the constructor using SFINAE is way too greedy. It disables all non-bool constructors.<\/strong><\/p>\n
Beside my longish explanation, an additional argument speaks against SFINAE and for a conditionally explicit constructor: performance. Simon Brand pointed out in his post “C++20’s Conditionally Explicit Constructors<\/a>“, that explicit(bool)<\/span> made the template instantiation for Visual Studio 2019 about 15% faster compared to SFINAE.<\/p>\n
With C++20, additional non-type template parameters are supported.<\/p>\n<\/p>\n
New non-type Template Parameter<\/h2>\n
With C++20, floating points and classes with constexpr<\/span> constructors are supported as non-types.<\/p>\n
C++ supports non-types as template parameters. Essentially non-types could be<\/p>\n