Using Concepts with Classes

In this lesson, we’ll build on our previous knowledge of concepts to learn how to apply them to test more elaborate types, such as those defined by classes. By the end of this lesson, you will be able to:

• Check for the existence of class members using requires expressions
• Constrain the types of member variables using type traits and concepts like std::integral and std::same_as
• Require class methods with specific parameter and return types using functional-style requires expressions
• Ensure classes implement equality comparison operators like == and != using concepts
• Combine multiple requirements within a concept to define comprehensive constraints on class templates

By mastering the techniques covered in this lesson, you'll be able to write more robust and expressive generic code using class templates. You'll catch errors at compile-time, provide clearer intentions about template requirements, and create more maintainable and self-documenting code.

Class Members

To check if a type has a specific member variable or function, we can use the scope resolution operator :: within a requires expression. Below, our Sized concept is satisfied if the type has a member called Size:

1#include <iostream>
2
3template <typename T>
4concept Sized = requires { T::Size; };
5
6struct Rock {
7  int Size;
8};
9
10int main() {
11  if constexpr (Sized<Rock>) {
12    std::cout << "Rock has a size";
13  }
14}

1Rock has a size

We can perform the same check within a functional-style requires expression as follows:

1template <typename T>
2concept Sized = requires(T x) {
3  T::Size;
4
5  // Alternatively:
6  x.Size;
7};

Remember, we can have multiple statements inside a requires expression, and we can combine expressions using boolean logic. Below, we require our type either have a Size member, or both a Width and Height member:

1template <typename T>
2concept Sized = requires {
3  T::Size;
4} || requires {
5  T::Width;
6  T::Height;
7};

Class Member Types

When we’re writing a concept that requires a type to have a specific member, we’ll typically also care about the exact nature of that member. In the following example, we check whether the Size member satisfies the std::integral concept:

1#include <concepts>
2#include <iostream>
3
4template <typename T>
5concept IntegerSized =
6  std::integral<decltype(T::Size)>;

Within a requires expression: our check could look like this:

1#include <concepts>
2
3template <typename T>
4concept IntegerSized = requires {
5  requires std::integral<decltype(T::Size)>;
6};

Requiring an Exact Type

When we want to check if the member matches an exact type, we can use the std::same_as concept. Below, we require our Size member to be exactly an int:

1template <typename T>
2concept IntegerSized =
3  std::same_as<int, decltype(T::Size)>;

However, an exact check like this is often more rigid than is necessary. For example, in most scenarios where our template requires an int, types like an int& or const int& would also be acceptable.

To handle this, we can perform our comparison with reference and / or const qualifiers removed from the type, using the std::remove_reference and std::remove_const type traits respectively.

We can remove both in a single step using the std::remove_cvref type trait:

1#include <concepts>
2
3template <typename T>
4concept IntegerSized =
5  std::same_as<int, std::remove_cvref_t<
6    decltype(T::Size)>>;

We covered this scenario, and type traits like std::remove_cvref in more detail earlier in the chapter:

Type Traits: Compile-Time Type Analysis

Learn how to use type traits to perform compile-time type analysis, enable conditional compilation, and enforce type requirements in templates.

Class Methods

Typically, the friendliest way to require our types to have specific methods is to use a functional requires expression, and then provide statements that use those methods.

In the following example, we require our type to have a Render() method that is invocable with no arguments:

1#include <iostream>
2
3template <typename T>
4concept Renderable = requires(T Object) {
5  Object.Render();
6};
7
8struct Rock {
9  void Render(){};
10};
11
12int main() {
13  if constexpr (Renderable<Rock>) {
14    std::cout << "Rock is renderable with no"
15      " arguments";
16  }
17}

1Rock is renderable with no arguments

1#include <iostream>
2
3template <typename T>
4void Call(T Function) {
5  Function();
6}
7
8void Greet() {
9  std::cout << "Hello";
10}
11
12int main() {
13  Call(&Greet);
14}

1Hello

1#include <iostream>
2#include <concepts>
3
4template <std::invocable T>
5void Call(T Function) {
6  Function();
7}
8
9void Greet() {
10  std::cout << "Hello";
11}
12
13int main() {
14  Call(&Greet);
15}

1Hello

1#include <iostream>
2#include <concepts>
3
4void Greet() {
5  std::cout << "Hello";
6}
7
8int main() {
9  if (std::invocable<decltype(&Greet)>) {
10    std::cout << "Greet is invocable";
11  }
12}

1Greet is invocable

1#include <iostream>
2
3template <typename T>
4concept Renderable =
5  std::invocable<decltype(&T::Render), T*>;
6
7struct Rock {
8  void Render(){};
9};
10
11int main() {
12  if constexpr (Renderable<Rock>) {
13    std::cout << "Rock is renderable with no"
14      " arguments";
15  }
16}

1Rock is renderable with no arguments

Method Parameter Types

To require our methods to be callable with specific argument types, we can simply pass example values within the statement. Below, we require the Render() method to be invocable with two int arguments.

The fact we’ve chosen 1 and 2 as the values is inconsequential - we can just use any values of the type we’re testing:

1#include <concepts>
2#include <iostream>
3
4template <typename T>
5concept Renderable = requires(T Object) {
6  Object.Render(1, 2);
7};
8
9struct Rock {
10  void Render(int x, int y){};
11};
12
13int main() {
14  if constexpr (Renderable<Rock>) {
15    std::cout << "Rock is renderable with "
16      "two integer arguments";
17  }
18}

1Rock is renderable with two integer arguments

We can alternatively add these as hypothetical arguments within the parameter list of our requires syntax. This lets us explicitly specify the type, and also give the variables a name, which can be help document our assumptions:

1template <typename T>
2concept Renderable =
3  requires(T Object, int Width, int Height) {
4    Object.Render(Width, Height);
5};

1template <typename T>
2concept Renderable = requires(T Object) {
3  Object.Render(
4    std::declval<int>(), std::declval<int>());
5};

Remember, our concepts are not restricted to a single template argument. Below, we update our Renderable concept to accept three arguments.

Two of them - R1 and R2 are used when testing the parameter list of the Render() method:

1#include <concepts>
2#include <iostream>
3
4template <typename T, typename R1, typename R2>
5concept Renderable =
6  requires(T Object, R1 x, R2 y) {
7    Object.Render(x, y);
8};
9
10struct Rock {
11  void Render(int x, float y){};
12};
13
14int main() {
15  if constexpr (Renderable<Rock, int, float>) {
16    std::cout << "Rock is renderable with "
17      "an int and a float";
18  }
19}

1Rock is renderable with an int and a float

Parameter Types with std::invocable

The std::invocable concept accepts additional template arguments, beyond the type we’re testing. These template arguments represent the types we want our function to be invocable with.

Below, we check whether &Greet is invocable with a std::string and an int:

1#include <concepts>
2#include <iostream>
3
4void Greet(std::string Greeting, int Num) {
5  std::cout << Greeting << ", Num: " << Num;
6}
7
8int main() {
9  if constexpr (std::invocable<
10    decltype(&Greet), std::string, int>) {
11    std::cout << "Greet is invocable with a "
12                 "std::string and an int";
13  }
14}

1Greet is invocable with a std::string and an int

Below, we’re using this concept to constrain a template type parameter.

Remember, when used in this context, the first argument to our concept is provided automatically during substitution, so we only provide the types our function will be invoked with:

1#include <iostream>
2#include <concepts>
3
4template <std::invocable<std::string, int> T>
5void Call(T Function) {
6  Function("Hello", 42);
7}
8
9void Greet(std::string Greeting, int Num) {
10  std::cout << Greeting << ", Num: " << Num;
11}
12
13int main() {
14  Call(&Greet);
15}

1Hello, Num: 42

Reviewing our earlier Renderable concept, we can see it used std::invocable like this, indicating that we’ll be calling T::Render with a pointer to a T:

1template <typename T>
2concept Renderable =
3  std::invocable<decltype(&T::Render), T*>;

This is typical with class methods. We can imagine the methods have a hidden argument, which will be a pointer to the object it was called on. For example, if we call SomeRock.Render(), the hidden parameter will be &SomeRock.

That is, it will be the value that is available through the this pointer within our method body.

The this Pointer

Learn about the this pointer in C++ programming, focusing on its application in identifying callers, chaining functions, and overloading operators.

In the following example, we update our Renderable concept to use std::invocable with additional parameter requirements:

1#include <iostream>
2#include <concepts>
3
4template <typename T, typename R1, typename R2>
5concept Renderable = std::invocable<
6  decltype(&T::Render), T*, R1, R2>;
7
8struct Rock {
9  void Render(int x, float y){};
10};
11
12int main() {
13  if constexpr (Renderable<Rock, int, float>) {
14    std::cout << "Rock is renderable with an"
15      " int and a float";
16  }
17}

1Rock is renderable with an int and a float

Method Return Types

The syntax to test a method’s return value within a concept is a little more complex. In the following example, we’re requiring our object to have a Render() method that accepts no arguments and returns something that satisfies the std::integral concept.:

1template <typename T>
2concept Renderable = requires(T Object) {
3	{ Object.Render() } -> std::integral;
4};

Commonly, we’ll want to assert that the return type matches a specific type, or is convertible to a specific type. The C++ specification requires us to provide a concept here rather than a type, but the standard library’s same_as and convertible_to concepts can cover our needs.

Below, we are requiring render to return an int:

1template <typename T>
2concept Renderable = requires(T Object) {
3	{ Object.Render() } -> std::same_as<int>;
4};

Below, we are requiring the Render() method to accept an argument of template parameter type A and return something convertible to another template parameter type, R:

1#include <concepts>
2#include <iostream>
3
4template <typename T, typename A, typename R>
5concept RenderReturns = requires(T Obj, A x) {
6  { Obj.Render(x) } -> std::convertible_to<R>;  
7};
8
9struct Rock {
10  int Render(int) { return 42; };
11};
12
13int main() {
14  if constexpr (RenderReturns<Rock, int, float>) {
15    std::cout << "Rock::Render(int) return type"
16      " is convertible to a float";
17  }
18}

1Rock::Render(int) return type is convertible to a float

Operators

As operators are essentially functions, we can test that a type has an operator in exactly the same way we’d test it have any other function.

Below, our concept requires that the type implement the == operator with another object of the same type being the right operand:

1template <typename T>
2concept Comparable = requires(T x, T y) {
3  x == y; 
4};

Below, we extend this to require the operator to return something that is convertible to a boolean:

1#include <concepts>
2#include <iostream>
3
4struct Container {
5  int Value;
6  bool operator==(const Container& Other) const {
7    return Other.Value != Value;
8  }
9};
10
11template <typename T>
12concept Comparable = requires(T x, T y) {
13  { x == y } -> std::convertible_to<bool>;  
14};
15
16int main() {
17  if constexpr (Comparable<Container>) {
18    std::cout << "Container is comparable";
19  }
20}

1Container is comparable

In this example, we expand the concept with an additional argument, allowing us to specify what type we’re going to be comparing our object to:

1#include <concepts>
2#include <iostream>
3
Container Struct|Show
4struct Container {/*...*/};
24
25template <typename T1, typename T2>
26concept ComparableTo = requires(T1 x, T2 y) {
27  { x == y } -> std::convertible_to<bool>;
28  { y == x } -> std::convertible_to<bool>;
29  { x != y } -> std::convertible_to<bool>;
30  { y != x } -> std::convertible_to<bool>;
31};
32
33int main() {
34  if constexpr (ComparableTo<Container, int>) {
35    std::cout << "Container is comparable to int";
36  }
37}

Note, similar concepts to what we made above are already available in the standard library:

1std::equality_comparable<Container>;
2std::equality_comparable_to<Container, int>

Summary

In this lesson, we learned how to use concepts to test for more elaborate requirements. The key takeaways include:

• Concepts allow you to define constraints on class instances, specifying requirements for member variables, member functions, and operators.
• You can check for the presence of specific member variables and functions using the scope resolution operator :: within requires expressions.
• Concepts like std::integral, std::floating_point, std::same_as, and type traits like std::is_base_of and std::is_integral can be used to constrain the types of class members.
• The friendly syntax for requiring methods uses a functional-style requires expression with example parameter values, allowing you to specify parameter and return types.
• Alternatively, methods can be checked for invocability with specific argument types using std::invocable and related concepts.
• Operators like == and != can be tested as normal functions within requires expressions.
• You can combine multiple requirements within a single concept using logical operators like && and || to define comprehensive constraints on class templates.

Next Lesson

Run Time Type Information (RTTI) and typeid()

Learn to identify and react to object types at runtime using RTTI, dynamic casting and the typeid() operator

ContinueView Course