{"id":5815,"date":"2019-11-21T18:29:55","date_gmt":"2019-11-21T18:29:55","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/concepts-two-extrems-and-the-solution\/"},"modified":"2023-06-26T09:57:45","modified_gmt":"2023-06-26T09:57:45","slug":"concepts-two-extrems-and-the-solution","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/concepts-two-extrems-and-the-solution\/","title":{"rendered":"C++20: Two Extremes and the Rescue with Concepts"},"content":{"rendered":"

I finished my overview of C++20 in the last post. Now, it’s time to dive into the details. What can be a better starting point for our journey than concepts?<\/p>\n

<\/p>\n

\"TimelineCpp20Concepts\"<\/p>\n

I must confess: I’m a big fan of concepts and, therefore, biased. Anyway, let’s start with a motivating example.<\/p>\n

Two Extremes<\/h2>\n

\"TwoExtrems\"<\/p>\n

Until C++20, we have in C++ two diametral ways to think about functions or classes. Functions or classes can be defined on specific types or on generic types. In the second case, we call them function or class templates. What is wrong with each way?<\/p>\n

Too Specific<\/h3>\n

It’s quite a job to define a function or class for each specific type. To avoid that burden, type conversion often comes to our rescue. What seems like rescue is often a curse.<\/p>\n

<\/p>\n

\n
\/\/ tooSpecific.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\nvoid<\/span> needInt<\/span>(int<\/span> i){\r\n    std::<\/span>cout <<<\/span> \"int: \"<\/span> <<<\/span> i <<<\/span> std::<\/span>endl;\r\n}\r\n\r\nint<\/span> main<\/span>(){\r\n\t\r\n    std::<\/span>cout <<<\/span> std::<\/span>boolalpha <<<\/span> std::<\/span>endl;\r\n\t\r\n    double<\/span> d{1.234<\/span>};                             \/\/ (1)N<\/span>\r\n    std::<\/span>cout <<<\/span> \"double: \"<\/span> <<<\/span> d <<<\/span> std::<\/span>endl;\r\n    needInt(d);                                  \/\/ (2)            <\/span>\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \r\n    bool<\/span> b{true<\/span>};                                \/\/ (3)<\/span>\r\n    std::<\/span>cout <<<\/span> \"bool: \"<\/span> <<<\/span> b <<<\/span> std::<\/span>endl;\r\n    needInt(b);                                  \/\/ (4)<\/span>\r\n\t\r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\t\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
In the first case (line 1), I start with a double<\/span> and end with an int<\/span> (line 2). In the second case, I start with a bool<\/span> (line 3) and also end with an int<\/span> (line 4).<\/p>\n
\"tooSpecific\"<\/p>\n
Narrowing Conversion<\/h4>\n
Invoking getInt(int a)<\/code> with a double g<\/code>gives you a narrowing conversion. Narrowing conversion is conversion which a loss of accuracy. I assume this is not what you want. <\/span> <\/code><\/p>\n
Integral Promotion<\/h4>\n
But the other way around is also not better. Invoking getInt(int a<\/span>) with a bool<\/span> promotes the bool<\/span> to int<\/span>. Surprised? Many C++ developers don’t know which type they will get when they add to boo<\/span>l’s.<\/p>\n
<\/p>\n
\n
template<\/span> <<\/span>typename<\/span> T><\/span>\r\nauto<\/span> add(T first, T second){\r\n    return<\/span> first +<\/span> second;\r\n}\r\n\r\nint<\/span> main(){\r\n    add(true<\/span>, false<\/span>);\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
C++ Insights<\/a> shows you the truth.<\/p>\n
\"addGeneric\"<\/p>\n
The template instantiation of the function template add<\/span> creates a full specialization (lines 6 – 12) with the return type int.<\/span><\/p>\n
My firm belief is that we need, for convenience reasons, the entire magic of conversions in C\/C++ to deal with the fact that functions only accept specific types.<\/strong><\/p>\n
Okay. Let’s do it the other way around. Write not specifically, but write generically. Maybe, writing generic code with templates is our rescue.<\/p>\n
Too Generic<\/h3>\n
Here is my first try. Sorting is such a generic idea. It should work for each container if the elements of the container are sortable. Let’s apply std::sor<\/span>t to a std::list.<\/span><\/p>\n
 <\/p>\n
<\/p>\n
\n
\/\/ sortList.cpp<\/span>\r\n\r\n#include <algorithm><\/span>\r\n#include <list><\/span>\r\n\r\nint<\/span> main<\/span>(){\r\n    \r\n    std::<\/span>list<<\/span>int<\/span>><\/span> myList{1<\/span>, 10<\/span>, 3<\/span>, 2<\/span>, 5<\/span>};\r\n    \r\n    std::<\/span>sort(myList.begin(), myList.end());\r\n    \r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
WOW! This is what you get when I try to compile the small program.<\/p>\n
\"sortList\"<\/p>\n
I don’t even want to decipher this message. What is going wrong? Let’s look closer at the signature of the used overload of std::sort.<\/span><\/p>\n
 <\/p>\n
<\/p>\n
\n
template<\/span><<\/span> class<\/span> RandomIt<\/span> ><\/span>\r\nvoid<\/span> sort( RandomIt first, RandomIt last );\r\n<\/pre>\n<\/div>\n
 <\/p>\n
std::sort<\/span> uses strange-named arguments such as RandomIT<\/span>. RandomIT<\/span> stands for a random access iterator. This is why the overwhelming error message, for which templates are infamous. A std::list<\/span> provides only a bidirectional iterator, but std:sort<\/span> requires a random access iterator. The structure of a std::list<\/span> makes this obvious.<\/p>\n
\"list\"<\/p>\n
When you study carefully the documentation on cppreference.com<\/a> page to std::sort<\/span>, you find something exciting: type requirements on std::sort.<\/span><\/p>\n<\/p>\n
Concepts to the Rescue<\/h3>\n
Concepts are the rescue because they put semantic constraints on a template parameter.<\/p>\n
Here are the already mentioned type requirements on std::sort.<\/span><\/p>\n