{"id":4985,"date":"2016-10-15T22:00:18","date_gmt":"2016-10-15T22:00:18","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/more-and-more-save\/"},"modified":"2023-06-26T12:39:14","modified_gmt":"2023-06-26T12:39:14","slug":"more-and-more-save","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/more-and-more-save\/","title":{"rendered":"More and More Save"},"content":{"rendered":"

In the post Statically checked <\/a>I wrote that the functions of the type-traits library are an ideal fit for static_assert.<\/span> The reason is that static_assert<\/span> requires a constant expression. The functions of the type-traits library provide a lot of checks which can be performed at compile time. With these posts, I will prove my statement.<\/p>\n

<\/p>\n

gcd – The first<\/h2>\n

Before I describe systematically the functionality of the type-traits library I will start in this post with an example. My starting point is the Euclid algorithm<\/a> to calculate the greatest common divisor of two numbers.<\/p>\n

It’s quite easy to implement the algorithm as a function template and feed it with various arguments.<\/p>\n

<\/p>\n

 <\/p>\n

<\/p>\n

\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28<\/pre>\n<\/td>\n
\n
\/\/ gcd.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\ntemplate<\/span><typename<\/span> T>\r\nT gcd(T a, T b){\r\n  if<\/span>( b == 0 ){ return<\/span> a; }\r\n  else<\/span>{\r\n    return<\/span> gcd(b, a % b);\r\n  }\r\n}\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  std::cout << \"gcd(100,10)= \"<\/span> <<  gcd(100,10)  << std::endl;\r\n  std::cout << \"gcd(100,33)= \"<\/span> << gcd(100,33) << std::endl;\r\n  std::cout << \"gcd(100,0)= \"<\/span> << gcd(100,0)  << std::endl;\r\n\r\n  std::cout << gcd(3.5,4.0)<< std::endl;\r\n  std::cout << gcd(\"100\"<\/span>,\"10\"<\/span>) << std::endl;\r\n\r\n  std::cout << gcd(100,10L) << gcd(100,10L) << std::endl;\r\n\r\n  std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
But the compilation of the program fails. The compiler tries in vain to instantiate the templates.<\/p>\n
 \"gcd\"<\/p>\n
The function template has two serious issues. First, it is too generic. So the function template accepts doubles<\/span> (line 21) and C strings (line 22). But it makes no sense to determine the greatest common divisor of both data types. The modulo operation for the double<\/span> and the C string values fails in line 9. But that’s not the only issue. Second, gcd<\/span> depend on one type parameter T.<\/span> This shows the function template signature gcd(T a, T b)<\/span>). a<\/span> and b<\/span> have to be of the same type T.<\/span> There is no conversion for type parameters. Therefore, the instantiation of gcd<\/span> with an int<\/span> type and a long<\/span> type (line 24) fails.  <\/span><\/span><\/p>\n
Thanks to the type-traits library the first issue is quickly solved. The second issue requires much more effort.<\/p>\n<\/p>\n
gcd – The second<\/h2>\n
I ignore for simplicity reasons in the rest of the post that both arguments have to be positive numbers. But back to the first issue. The static_assert<\/span> operator and the predicate std::is_integral<T>::value<\/span> helps me to check at compile time <\/span>whether T<\/span> is an integral type. A predicate always returns a boolean value. <\/p>\n
<\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24<\/pre>\n<\/td>\n
\n
\/\/ gcd_2.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <type_traits><\/span>\r\n\r\ntemplate<\/span><typename<\/span> T>\r\nT gcd(T a, T b){\r\n  static_assert(std::is_integral<T>::value, \"T should be an integral type!\"<\/span>);\r\n  if<\/span>( b == 0 ){ return<\/span> a; }\r\n  else<\/span>{\r\n    return<\/span> gcd(b, a % b);\r\n  }\r\n}\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  std::cout << gcd(3.5,4.0)<< std::endl;\r\n  std::cout << gcd(\"100\"<\/span>,\"10\"<\/span>) << std::endl;\r\n\r\n  std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
Great. I have solved the first issue of the gcd algorithm. The compilation will not fail by accident because the modulo operator is not defined for a double<\/span> value and a C string. The compilation fails because the assertion in line 8 will not hold true. The subtle difference is that I now get an exact error message and not a cryptic output of a failed template instantiation as in the first example.<\/p>\n
 \"gcd<\/p>\n
The rule is quite simple. A compilation has to fail and I should get an unambiguous error message. <\/strong><\/p>\n
But what’s about the second issue. The gcd algorithm should accept arguments of a different type.<\/p>\n
gcd – The third<\/h2>\n
 That no big deal. But stop. What is the type of the result? <\/p>\n
<\/p>\n
\n\n\n\n
\n
1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9<\/pre>\n<\/td>\n
\n
template<\/span><typename<\/span> T1, typename<\/span> T2>\r\n??? gcd(T1 a, T2 b){\r\n  static_assert(std::is_integral<T1>::value, \"T1 should be an integral type!\"<\/span>);\r\n  static_assert(std::is_integral<T2>::value, \"T2 should be an integral type!\"<\/span>);\r\n  if<\/span>( b == 0 ){ return<\/span> a; }\r\n  else<\/span>{\r\n    return<\/span> gcd(b, a % b);\r\n  }\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The three questions marks in line 2 show the core of the issue. Should the first type or the second type be the return type of the algorithm? Or should the algorithm derive a new type from the two arguments? The type-traits library comes to my rescue. I will present two variations.<\/p>\n
 <\/p>\n
The smaller type<\/h3>\n
A good choice for the return type is to use the smaller of both types. Therefore, I need a ternary operator at compile time. Thanks to the type-traits library we have. The ternary function std::conditional<\/span> operates on types and not on values. That’s because we apply the function at compile time. So we have to feed std::conditional<\/span> with the right constant expression and we are done. std::conditional<(sizeof(T1) < sizeof(T2)), T1, T2>::type<\/span> will return at compile time T1<\/span> if T1<\/span> is smaller than T2<\/span>; it will return T2<\/span> if T1<\/span> is not smaller than T1<\/span>. <\/p>\n
Let’s apply the logic. <\/p>\n
 <\/p>\n
<\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38<\/pre>\n<\/td>\n
\n
\/\/ gcd_3_smaller.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <type_traits><\/span>\r\n#include <typeinfo><\/span>\r\n\r\ntemplate<\/span><typename<\/span> T1, typename<\/span> T2>\r\ntypename<\/span> std::conditional <(sizeof<\/span>(T1) < sizeof<\/span>(T2)), T1, T2>::type gcd(T1 a, T2 b){\r\n  static_assert(std::is_integral<T1>::value, \"T1 should be an integral type!\"<\/span>);\r\n  static_assert(std::is_integral<T2>::value, \"T2 should be an integral type!\"<\/span>);\r\n  if<\/span>( b == 0 ){ return<\/span> a; }\r\n  else<\/span>{\r\n    return<\/span> gcd(b, a % b);\r\n  }\r\n}\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  std::cout << \"gcd(100,10)= \"<\/span> <<  gcd(100,10)  << std::endl;\r\n  std::cout << \"gcd(100,33)= \"<\/span> << gcd(100,33) << std::endl;\r\n  std::cout << \"gcd(100,0)= \"<\/span> << gcd(100,0)  << std::endl;\r\n\r\n  std::cout << std::endl;\r\n\r\n  std::cout << \"gcd(100,10LL)= \"<\/span> << gcd(100,10LL) << std::endl;\r\n\r\n  std::conditional <(sizeof<\/span>(100) < sizeof<\/span>(10LL)), long<\/span> long<\/span>, long<\/span>>::type uglyRes= gcd(100,10LL);\r\n  auto<\/span> res= gcd(100,10LL);\r\n  auto<\/span> res2= gcd(100LL,10L);\r\n\r\n  std::cout << \"typeid(gcd(100,10LL)).name(): \"<\/span> << typeid<\/span>(res).name() << std::endl;\r\n  std::cout << \"typeid(gcd(100LL,10L)).name(): \"<\/span> << typeid<\/span>(res2).name() << std::endl;\r\n\r\n  std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The key line of the program is the line 8 with the return type of the gcd<\/span> algorithm. Of course, the algorithm can also deal with templates arguments of the same type. You can observe it in line 21 to 24 and the output of the program. But what’s about line 27? I use the number 100 of type int<\/span> and the number 10 of type long long int. T<\/span>he result for the greatest common divisor is 10. The line 29 is extremely ugly. I have to repeat the expression std::conditional <(sizeof(100) < sizeof(10LL)), long long, long>::type<\/span> to determine the right type of the variable uglyRes.<\/span> <\/span>Automatic type deduction with auto<\/span> <\/span>comes to my rescue (line 30 and 31). The typeid<\/span> operator in line 33 and 34 shows that the result type of the arguments of type int<\/span> and long long int<\/span> is int<\/span><\/strong>;<\/span> that the result type of the types long long int<\/span> and long int<\/span> is long int<\/span><\/strong>.  <\/p>\n
 <\/p>\n
 \"gcd<\/p>\n
The common type<\/h3>\n
Now to my second variation. Often it is not necessary to determine the smaller type at compile time but to determine that type to which all types can implicitly be converted to. That’s the job of the function template std::common_type<\/span> from the – of course you know it already – type-traits library. std::common_type<\/span> can handle an arbitrary number of template arguments. To say it more formally. std::common_type<\/span> is a variadic template. <\/a><\/p>\n
 <\/p>\n
<\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27<\/pre>\n<\/td>\n
\n
\/\/ gcd_3_common.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <type_traits><\/span>\r\n#include <typeinfo><\/span>\r\n\r\ntemplate<\/span><typename<\/span> T1, typename<\/span> T2>\r\ntypename<\/span> std::common_type<T1, T2>::type gcd(T1 a, T2 b){\r\n  static_assert(std::is_integral<T1>::value, \"T1 should be an integral type!\"<\/span>);\r\n  static_assert(std::is_integral<T2>::value, \"T2 should be an integral type!\"<\/span>);\r\n  if<\/span>( b == 0 ){ return<\/span> a; }\r\n  else<\/span>{\r\n    return<\/span> gcd(b, a % b);\r\n  }\r\n}\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  std::cout << \"typeid(gcd(100,10)).name(): \"<\/span> << typeid<\/span>(gcd(100,10)).name() << std::endl;\r\n  std::cout << \"typeid(gcd(100,10L)).name(): \"<\/span> << typeid<\/span>(gcd(100,10L)).name() << std::endl;\r\n  std::cout << \"typeid(gcd(100,10LL)).name(): \"<\/span> << typeid<\/span>(gcd(100,10LL)).name() << std::endl;\r\n\r\n  std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The only difference to the last implementation is that std::common_type<\/span> in line 8 determines the return type. I ignore in this example the results of the gcd because I’m more interested in the types of the results. With the argument types int<\/span> and int int<\/span> I get int<\/span><\/strong>; with the argument types int<\/span> and long int long int<\/strong><\/span>; with int<\/span> and long long int long long int<\/strong><\/span>.<\/p>\n
<\/span><\/p>\n
 \"gcd<\/p>\n
gcd – The fourth<\/h2>\n
But that’s not all. std::enable_if<\/span> from the type-traits library also provides a very interesting variation. The previous implementations have in common that they will check in the function body If the arguments are integral types. The key observation is that the compiler always tries to instantiate the function temples and fails sometimes. You know the result. If the expression std::integral<\/span> returns fall, the instantiation will fail. That is not the best way. It would be better if the function template is only available for the valid types. Therefore, I put the check of the function template from the template body to the template signature.<\/p>\n
I order to concentrate on the essentials, I used the same type for the function arguments. Therefore, the return type is obvious.<\/p>\n
<\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24<\/pre>\n<\/td>\n
\n
\/\/ gcd_4.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <type_traits><\/span>\r\n\r\ntemplate<\/span><typename<\/span> T,\r\n         typename<\/span> std::enable_if<std::is_integral<T>::value,T>::type= 0>       \r\nT gcd(T a, T b){\r\n  if<\/span>( b == 0 ){ return<\/span> a; }\r\n  else<\/span>{\r\n    return<\/span> gcd(b, a % b);\r\n  }\r\n}\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  std::cout << \"gcd(100,10)= \"<\/span> <<  gcd(100,10)  << std::endl;\r\n  std::cout << \"gcd(3.5,4)= \"<\/span> << gcd(3.5,4.0) << std::endl;     \r\n\r\n  std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
Line 7 is the critical line of the new program. The expression std::is_integral<\/span> determines whether the type parameter T is integral. If T is not integral and, therefore, the return value false<\/span>, I will not get a template instantiation. This is the decisive observation.<\/p>\n
If std::enable_if<\/span> returns true<\/span> as the first parameter, std::enable_if<\/span> will have a public member<\/span> typedef<\/span> type.<\/span> This type is used in line 7. If std::enable_if<\/span> returns false<\/span> as the first parameter, std::enable_if<\/span> will have no public member typedef type. <\/span>Therefore line 7 is not valid. But this is not an error. Only the template for precisely this type will not be instantiated.  <\/span><\/p>\n
The rule in C++ says: When substituting the deduced type for the template parameter fails, the specialization is discarded from the overload set instead of causing a compile error. There is a shorter acronym for this rule SFINAE<\/a> (S<\/strong>ubstitution F<\/strong>ailure I<\/strong>s N<\/strong>ot A<\/strong>n E<\/strong>rror).<\/p>\n
The output of the compilation shows it. There is no template specialization for the type double.<\/span> <\/p>\n
 \"gcd<\/p>\n
What’s next?<\/span><\/h2>\n
The next post about the type-traits library will be systematic. The type-traits library has a lot of functions. They enable you to check, compare, and modify types at compile time. I will answer the two questions in the next post<\/a>. How does it work? And. Which functions are available?<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p><\/p>\n","protected":false},"excerpt":{"rendered":"
In the post Statically checked I wrote that the functions of the type-traits library are an ideal fit for static_assert. The reason is that static_assert requires a constant expression. The functions of the type-traits library provide a lot of checks which can be performed at compile time. With these posts, I will prove my statement.<\/p>\n","protected":false},"author":21,"featured_media":4980,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[364],"tags":[518,419],"class_list":["post-4985","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-embedded","tag-static_assert","tag-type-traits"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4985","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=4985"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4985\/revisions"}],"predecessor-version":[{"id":6936,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4985\/revisions\/6936"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/4980"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=4985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=4985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=4985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}