![\"dice](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/10\/dice-3613500_1280.png\")
<\/p>\nWe will get concepts with high probability in C++20. Here are the rules from the C++ core guidelines to use them.<\/p>\n
<\/p>\n
<\/p>\n
First, let me go one step back. What are concepts?<\/p>\n
The following questions are. What are the pros of concepts in C++? <\/p>\n
<\/p>\n
Concepts<\/strong><\/p>\n Now, one step forward. Here are the four rules for today:<\/p>\n Let’s start with the first rule.<\/p>\n There is not much to add to this rule. Because of correctness and readability, you should use concepts for all template parameters. You can do it in a verbose way.<\/p>\n <\/p>\n Or you can do it more concisely.<\/p>\n <\/p>\n In the first example, I specify the concept in the required clause, but I can use the concept I created the concept by using <\/p>\n Defining your concepts, as I did, is not the best idea.<\/p>\n<\/p>\n Okay, if possible, you should use the concepts from the Guidelines Support Library (GSL) or the Ranges TS. Let’s see what we have. I ignore the concepts of the GSL because they are mainly part of the Ranges TS. Here are the concepts of the Range TS from the document N4569<\/a>: Working Draft, C++ Extension for Ranges.<\/p>\n If you want to know what each of these concepts means, the already mentioned document N4569<\/a> gives you the answers. The concept definitions are based on the type traits library<\/a>. Here are for example, the definitions of the concepts <\/p>\n The functions Additionally, the names are used in the text of the C++ standard to define the expectations of the standard library. They are concepts that are not enforced but document the requirement for an algorithm, such as <\/p>\n The first overload of For the details to the named requirements used in the text of the C++ standard, read cppreference.com<\/a>. <\/span><\/p>\n Here is an example to make my point. <\/p>\n\n
\n
auto<\/code> for local variables<\/a><\/li>\nT.10: Specify concepts for all template arguments<\/a><\/h2>\n
\ntemplate<\/span><typename<\/span> T>\r\nrequires Integral<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<\/pre>\n<\/div>\n\ntemplate<\/span><Integral 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<\/pre>\n<\/div>\nIntegral<\/code> just in place of the keyword typename or class. The concept Integral<\/code> has to be a constant expression that returns a boolean. <\/p>\nstd::is_integral<\/span><\/code> from the type traits library.<\/p>\n\ntemplate<\/span><typename<\/span> T>\r\nconcept bool<\/span> Integral(){\r\n return<\/span> std::is_integral<T>::value;\r\n}\r\n<\/pre>\n<\/div>\nT.11: Whenever possible, use standard concepts<\/a><\/h2>\n
Core language concepts<\/h3>\n
\n
Same<\/code><\/li>\nDerivedFrom<\/code><\/li>\nConvertibleTo<\/code><\/li>\nCommon<\/code><\/li>\nIntegral<\/code><\/li>\nSigned Integral<\/code><\/li>\nUnsigned Integral<\/code><\/li>\nAssignable<\/code><\/li>\nSwappable<\/code><\/li>\n<\/ul>\nComparison concepts<\/h3>\n
\n
Boolean<\/code><\/li>\nEqualityComparable<\/code><\/li>\nStrictTotallyOrdered<\/code><\/li>\n<\/ul>\nObject concepts<\/h3>\n
\n
Destructible<\/code><\/li>\nConstructible<\/code><\/li>\nDefaultConstructible<\/code><\/li>\nMoveConstructible<\/code><\/li>\nCopy Constructible<\/code><\/li>\nMovable<\/code><\/li>\nCopyable<\/code><\/li>\nSemiregular<\/code><\/li>\nRegular<\/code><\/li>\n<\/ul>\nCallable concepts<\/h3>\n
\n
Callable<\/code><\/li>\nRegularCallable<\/code><\/li>\nPredicate<\/code><\/li>\nRelation<\/code><\/li>\nStrictWeakOrder<\/code><\/li>\n<\/ul>\nIntegral, Signed Integral<\/code>, and Unsigned Integral<\/code>.<\/p>\n\ntemplate<\/span> <<\/span>class<\/span> T<\/span>><\/span>\r\nconcept bool<\/span> Integral() {\r\n return<\/span> is_integral<<\/span>T>::<\/span>value;\r\n}\r\n\r\ntemplate<\/span> <<\/span>class<\/span> T<\/span>><\/span>\r\nconcept bool<\/span> SignedIntegral() {\r\n return<\/span> Integral<<\/span>T><\/span>() &&<\/span> is_signed<<\/span>T>::<\/span>value;\r\n}\r\n\r\ntemplate<\/span> <<\/span>class<\/span> T<\/span>><\/span>\r\nconcept bool<\/span> UnsignedIntegral() {\r\n return<\/span> Integral<<\/span>T><\/span>() &&<\/span> !<\/span>SignedIntegral<<\/span>T><\/span>();\r\n}\r\n<\/pre>\n<\/div>\nstd::is_integral<T><\/code> and std::is_signed<T><\/code> are predicates from the type traits library.<\/p>\nstd::sort<\/code><\/a>. <\/span><\/p>\n\ntemplate<\/span><<\/span> class<\/span> RandomIt<\/span> ><\/span>\r\nvoid<\/span> sort( RandomIt first, RandomIt last );\r\n<\/pre>\n<\/div>\nstd::sort<\/code> requires two RandomAccessIterator<\/strong>. Now, I have to say what a RandomAccessIterator<\/strong> is:<\/p>\n\n
T.12: Prefer concept names over
auto<\/code> for local variables<\/a><\/h2>\nauto<\/code> is an unconstrained concept (placeholder), but you should use constrained concepts. You can use constrained concepts in each situation, where you can use unconstrained placeholders (<\/span>auto<\/span>). <\/span>If this is not an intuitive rule?<\/p>\n\n\/\/ constrainedUnconstrainedConcepts.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <type_traits><\/span>\r\n#include <vector><\/span>\r\n\r\ntemplate<\/span><<\/span>typename<\/span> T><\/span> \/\/ (1)<\/span>\r\nconcept bool<\/span> Integral(){ \r\n return<\/span> std::<\/span>is_integral<<\/span>T>::<\/span>value;\r\n}\r\n\r\nint<\/span> getIntegral(int<\/span> val){\r\n return<\/span> val *<\/span> 5<\/span>;\r\n}\r\n\r\nint<\/span> main(){\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>boolalpha <<<\/span> std::<\/span>endl;\r\n \r\n std::<\/span>vector<<\/span>int<\/span>><\/span> myVec{1<\/span>, 2<\/span>, 3<\/span>, 4<\/span>, 5<\/span>};\r\n for<\/span> (Integral&<\/span> i:<\/span> myVec) std::<\/span>cout <<<\/span> i <<<\/span> \" \"<\/span>;