Exercises — Concepts (C++20) — constraining templates

A concept is a constexpr bool, so each is literally true or false.

• Numeric<int> → true (std::integral<int> is true).
• Numeric<double> → true (std::floating_point<double> is true).
• Numeric<bool> → true. Surprise! In C++ bool is an integral type, so std::integral<bool> is true.
• Numeric<char> → true. char is also integral.
• Numeric<std::string> → false (neither integral nor floating).
• Numeric<float*> → false. A pointer to float is not a floating-point type; pointers are not integral either.

Count of true: 4 (int, double, bool, char).

All four (a, b, c, d) are legal and equivalent. They are the four syntaxes from the parent note: abbreviated function template, constrained template parameter, requires-clause, trailing requires-clause. Number of legal forms: 4.

A candidate whose constraint is false is silently removed; the call fails only if zero remain.

• f(5) → int is integral → (A) survives, (B) removed → (A).
• f(3.14) → double is floating → (B).
• f('a') → char is integral → (A).
• f(2.0f) → float is floating → (B).
• f(true) → bool is integral → (A).
• f("hi") → const char* is neither → both removed → error ("no matching function call").

Chosen: A, B, A, B, A, error. Number of successful calls: 5.

#include <concepts>   // for std::same_as
 
template<typename T>
concept Addable = requires(T a, T b) {
    { a + b } -> std::same_as<T>;
};

requires(T a, T b) declares fictional test variables. { a + b } is a compound requirement: the expression must compile, and -> std::same_as<T> pins its type to exactly T.

• Addable<int> → int + int is int → true.
• Addable<std::string> → string + string is a std::string → true.

Both hold: 2 of 2 true.

g(-7) calls (B). int satisfies both Integral and SignedIntegral, so both candidates survive. When two candidates both apply, subsumption breaks the tie: SignedIntegral is defined as Integral<T> && ..., so it requires strictly more. The compiler prefers the more-constrained overload → (B).

g(7u) calls (A). unsigned is integral but not signed, so SignedIntegral<unsigned> is false → (B) is removed. Only (A) survives → (A). No ambiguity because only one candidate remains.

Subsumption compares constraints by their atomic constraint structure, not by logical truth. Two constraints subsume only when one is syntactically built from the same atomic pieces as the other (broken into && / || "atoms"). std::integral<T> is one atom; std::integral<T> == true is a different atom (a comparison expression). The compiler treats them as unrelated atoms and cannot prove one implies the other — so neither subsumes the other, and if both apply you get an ambiguity error. Lesson: express refinements by reusing the same named concept with &&, never by rewriting the condition.

#include <iostream>   // std::cout, operator<<
#include <iterator>   // std::begin, std::end
 
template<typename R>
concept Printable = requires(R r) {
    std::begin(r);   // (1) simple requirement: iterable
    std::end(r);
    requires requires(decltype(*std::begin(r)) x) {   // (2) see terminology note below
        std::cout << x;
    };
};
 
template<Printable R>
void print_all(const R& r) {
    for (const auto& x : r) std::cout << x << ' ';
}

Terminology — get the two requires straight (this is the confusing part):

• requires(R r) { ... } — this outermost one is the requires-expression. It opens a { ... } list of requirements and, as a whole, evaluates to a bool. concept Printable = <that bool>.
• Lines std::begin(r); and std::end(r); are simple requirements — each just has to compile.
• The line requires requires(...) { ... }; contains both kinds of requires back-to-back:
  • The first word requires is a nested requirement — a requirement whose job is "the following constraint must hold". A nested requirement always starts with the keyword requires.
  • The second requires(decltype(*std::begin(r)) x) { std::cout << x; } is a fresh, inner requires-expression. It introduces a fictional element x (whose type is the element type decltype(*std::begin(r))) and demands std::cout << x compiles.

So the pattern requires requires(...) = (nested requirement keyword) + (a whole new requires-expression). We need the nested form here because we want to test a constraint about the element type, not about R directly.

• Result: std::vector<int> satisfies Printable; std::vector<NoStreamType> is rejected at the call site, not deep inside the loop.

Why std::llround? The spec says "round to the nearest integer, as a long long". The standard library function that does exactly that in one call is std::llround (from #include <cmath>): it takes a floating value and returns a long long, rounding half away from zero. That is why we use it rather than, say, a plain (long long) cast — a bare cast truncates toward zero and would not satisfy "round to nearest" (e.g. (long long)3.7 == 3, wrong). We deliberately swap in llround precisely because it matches the "nearest, as long long" requirement.

#include <concepts>   // std::integral, std::floating_point
#include <cmath>      // std::llround
 
template<std::integral T>
long long to_number(T x) { return x; }                    // (A)
 
template<std::floating_point T>
long long to_number(T x) { return std::llround(x); }      // (B)  returns long long directly

• to_number(42) → int → (A) → 42.
• to_number(3.7) → double → (B) → llround(3.7) = 4.
• to_number(-2.4) → double → (B) → llround(-2.4) = -2 (nearest integer; -2.4 rounds toward -2).

Answers: 42, 4, -2.

A constrained template is preferred over a less-constrained/unconstrained one when both are viable. Among constrained ones, subsumption picks the more-constrained.

• h(int{}) → sizeof(int)==4. Viable: (A) always, (B) integral true, (C) integral && 4>=4 true. (C) subsumes (B) subsumes (A) → (C).
• h(char{}) → integral true but sizeof(char)==1 < 4 → (C) removed. Viable: (A), (B). (B) is constrained, (A) is not → (B).
• h(3.14) → double not integral → (B), (C) removed. Only (A) survives → (A).

Chosen: (C), (B), (A).

Note on subsumption: (C)'s clause requires (sizeof(T) >= 4) is an extra atom on top of integral; because (B) and (C) share the std::integral<T> atom, (C) is recognised as strictly more-constrained. This is the correct way to refine (contrast Exercise 3.2).

First, std::convertible_to<X, Y> is another standard concept from <concepts>: it is true when an X can be implicitly converted to Y. Here { t.size() } -> std::convertible_to<std::size_t> means "t.size() compiles and its result converts to std::size_t".

• std::vector<int> → has value_type, .size() returning std::size_t, and .begin() → true.
• int → has no nested value_type, no .size(), no .begin() → the type requirement (i) fails first → false.
• std::array<double,0> → this is the degenerate case: a zero-length container. Container asks only whether the operations exist, not whether the container is non-empty. std::array<double,0> still has value_type = double, still has a valid .size() (returning 0), and still has .begin() (equal to .end()). So the concept holds → true.

Edge lesson: concepts test the shape of the type's interface, never runtime contents. An empty range is a valid range; the concept correctly says true.

L1 true-count for Numeric ::: 4 (int, double, bool, char) L2 f("hi") outcome ::: error — both overloads removed L3 g(-7) chooses ::: (B) SignedIntegral, by subsumption L4 to_number(3.7) ::: 4 L4 to_number(-2.4) ::: -2 L5 h(char{}) chooses ::: (B), because (C)'s size constraint is false L5 Container<std::array<double,0>> ::: true — interface exists even for an empty container