![\"cat](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/11\/cat-633081_1280.jpg\")
<\/p>\nThere is, in particular, one rule left to template interfaces which are quite interesting: T.47: Avoid highly visible unconstrained templates with common names. Admittedly, the rule T47 is often the reason for unexpected behavior because the wrong function is called.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Although I write today mainly about rule T.47, I have more to say.<\/p>\n
enable_if<\/code><\/a><\/li>\n- T.49: Where possible, avoid type-erasure<\/a><\/li>\n<\/ul>\n
The get to the point of rule T.47, I have to make a short detour. This detour is about argument-dependent lookup (ADL) also known as Koenig lookup named after Andrew Koenig<\/a>. First of all. What is an argument-dependent lookup?<\/p>\nArgument-Dependent Lookup (ADL)<\/h2>\n
Here is the definition of ADL:<\/p>\n
\n- Argument-dependent lookup<\/strong> is a set of rules for looking up unqualified function names. Unqualified function names are additionally looked up in the namespace of their arguments.\n<\/li>\n<\/ul>\n
Unqualified function names mean functions without the <\/code>scope operator (::).. Is argument-dependent lookup bad? Of course not; ADL makes our life as a programmer easier. Here is an example.<\/p>\n <\/p>\n
\n#include <iostream><\/span>\r\n\r\nint<\/span> main<\/span>(){\r\n std::<\/span>cout <<<\/span> \"Argument-dependent lookup\"<\/span>; \r\n}\t\r\n<\/pre>\n<\/div>\n <\/p>\n
Fine. Let me remove the syntactic sugar of operator overloading and use the function call directly.<\/p>\n
<\/p>\n
\n#include <iostream><\/span>\r\n\r\nint<\/span> main<\/span>(){\r\n operator<\/span><<<\/span>(std::<\/span>cout, \"Argument-dependent lookup\"<\/span>);\r\n}\t\r\n<\/pre>\n<\/div>\n <\/p>\n
This equivalent program shows what is happening under the hood. The function operator<<<\/span> is called with the arguments std::<\/span>cout and a C-string “Argument-dependent lookup”<\/span>.<\/p>\nFine? No? The question arises: Where is the definition of the function operator<<<\/span>. Of course, there is no definition in the global namespace. operator<<<\/span> is an unqualified function name; therefore, argument-dependent lookup kicks in. The function name is additionally looked up in the namespace of their arguments. In this particular case, the namespace std<\/span> is due to the first argument std::cout<\/span> considered, and the lookup finds the appropriate candidate: std::operator<<(std::ostream&, const char*). <\/span>Often ADL provides you precisely with the function you are looking for, but sometimes… <\/span><\/p>\nNow, it is the right time to write about rule T.47:<\/p>\n<\/p>\n
T.47: Avoid highly visible unconstrained templates with common names<\/a><\/h2>\nIn the expression std::cout << “Argument-dependent lookup”<\/span>, the overloaded output operator <<<\/span> is the obvious common name because it is defined in the namespace std<\/span>. The following program, based on the program of the core guidelines, shows the crucial point of this rule.<\/p>\n <\/p>\n
\n\/\/ argumentDependentLookup.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <vector><\/span>\r\n\r\nnamespace<\/span> Bad{\r\n \r\n struct<\/span> Number{ \r\n int<\/span> m; \r\n };\r\n \r\n template<\/span><<\/span>typename<\/span> T1, typename<\/span> T2><\/span> \/\/ generic equality (5)<\/span>\r\n bool<\/span> operator<\/span>==<\/span>(T1, T2){ \r\n return<\/span> false<\/span>; \r\n }\r\n \r\n}\r\n\r\nnamespace<\/span> Util{\r\n \r\n bool<\/span> operator<\/span>==<\/span>(int<\/span>, Bad::<\/span>Number){ \/\/ equality to int (4)<\/span>\r\n return<\/span> true<\/span>; \r\n } \r\n\r\n void<\/span> compareSize(){\r\n Bad::<\/span>Number badNumber{5<\/span>}; \/\/ (1)<\/span>\r\n std::<\/span>vector<<\/span>int<\/span>><\/span> vec{1<\/span>, 2<\/span>, 3<\/span>, 4<\/span>, 5<\/span>};\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>boolalpha <<<\/span> std::<\/span>endl;\r\n \r\n std::<\/span>cout <<<\/span> \"5 == badNumber: \"<\/span> <<<\/span> \r\n (5<\/span> ==<\/span> badNumber) <<<\/span> std::<\/span>endl; \/\/ (2) <\/span>\r\n std::<\/span>cout <<<\/span> \"vec.size() == badNumber: \"<\/span> <<<\/span> \r\n (vec.size() ==<\/span> badNumber) <<<\/span> std::<\/span>endl; \/\/ (3)<\/span>\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n }\r\n}\r\n\r\nint<\/span> main(){\r\n \r\n Util::<\/span>compareSize();\r\n\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
I expect that in both cases (2 and 3), the overloaded operator ==<\/span> in Line (4) is called because it takes an argument of type Bad::Number<\/span> (1); <\/span>therefore, I should get two times true.<\/span><\/p>\n ![\"argumentDependentLookup\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/11\/argumentDependentLookup.png\")
<\/p>\n
What happened here? The call in line (3) is resolved by the generic equality operator in line (5)? The reason for my surprise is that vec.size()<\/span> returns a value of type std::size_type<\/span>, which is an unsigned integer type. This means the equality operator requires a conversation to int in<\/code> line (4). This is unnecessary for the generic equality in line (5) because this is a fit without conversion. Thanks to argument-dependent lookup, the generic equality operator belongs to the set of possible overloads.<\/p>\nThe rule states “Avoid highly visible unconstrained templates with common names”. Let me see what would happen if I followed the rule and disable the generic equality operator. Here is the fixed code.<\/p>\n
<\/p>\n
\n\/\/ argumentDependentLookupResolved.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <vector><\/span>\r\n\r\nnamespace<\/span> Bad{\r\n \r\n struct<\/span> Number{ \r\n int<\/span> m; \r\n };\r\n \r\n}\r\n\r\nnamespace<\/span> Util{\r\n \r\n bool<\/span> operator<\/span>==<\/span>(int<\/span>, Bad::<\/span>Number){ \/\/ compare to int (4)<\/span>\r\n return<\/span> true<\/span>; \r\n } \r\n\r\n void<\/span> compareSize(){\r\n Bad::<\/span>Number badNumber{5<\/span>}; \/\/ (1)<\/span>\r\n std::<\/span>vector<<\/span>int<\/span>><\/span> vec{1<\/span>, 2<\/span>, 3<\/span>, 4<\/span>, 5<\/span>};\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>boolalpha <<<\/span> std::<\/span>endl;\r\n \r\n std::<\/span>cout <<<\/span> \"5 == badNumber: \"<\/span> <<<\/span> \r\n (5<\/span> ==<\/span> badNumber) <<<\/span> std::<\/span>endl; \/\/ (2) <\/span>\r\n std::<\/span>cout <<<\/span> \"vec.size() == badNumber: \"<\/span> <<<\/span> \r\n (vec.size() ==<\/span> badNumber) <<<\/span> std::<\/span>endl; \/\/ (3)<\/span>\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n }\r\n}\r\n\r\nint<\/span> main(){\r\n \r\n Util::<\/span>compareSize();\r\n\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Now, the result matches my expectations.<\/p>\n
![\"argumentDependentLookupResolved\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/11\/argumentDependentLookupResolved.png\")
<\/p>\n
Here are my remarks on the last two rules for template interfaces.<\/p>\n
T.48: If your compiler does not support concepts, fake them with enable_if<\/code><\/a><\/h2>\nWhen I present std::enable_if<\/span> in my seminars, a few participants are slightly scared. Here is the simplified version of a generic greatest common divisor algorithm.<\/p>\n\n\/\/ enable_if.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <type_traits><\/span>\r\n\r\ntemplate<\/span><<\/span>typename<\/span> T, \/\/ (1)<\/span>\r\n typename<\/span> std::<\/span>enable_if<<\/span>std::<\/span>is_integral<<\/span>T>::<\/span>value, T>::<\/span>type=<\/span> 0<\/span>><\/span> \r\nT gcd(T a, T b){\r\n if<\/span>( b ==<\/span> 0<\/span> ){ return<\/span> a; }\r\n else<\/span>{\r\n return<\/span> gcd(b, a %<\/span> b); \/\/ (2)<\/span>\r\n }\r\n}\r\n\r\nint<\/span> main(){\r\n\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \/\/ (3)<\/span>\r\n std::<\/span>cout <<<\/span> \"gcd(100, 10)= \"<\/span> <<<\/span> gcd(100<\/span>, 10<\/span>) <<<\/span> std::<\/span>endl;\r\n std::<\/span>cout <<<\/span> \"gcd(3.5, 4)= \"<\/span> <<<\/span> gcd(3.5<\/span>, 4.0<\/span>) <<<\/span> std::<\/span>endl; \r\n\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
The algorithm is way too generic. It should only work for integral types. Now, std::enable_if<\/span> from the type-traits <\/a>library in line (1) comes to my rescue.<\/p>\nThe expression std::is_integral<\/span> (line 2) is critical for understanding the program. This line determines whether the type parameter T is integral. If T is not integral and, therefore, the return value false<\/span>, there will be no template instantiations for this specific type.<\/p>\nOnly if std::is_integral<\/span> returns true <\/span>std::enable_if<\/span> has a public member typedef type.<\/span> Suppose line (1) is not valid. But this is not an error. <\/span><\/p>\nThe C++ standard 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