Concepts in the C++ programming language are type constraints on templates (or generics). Concepts are named Boolean predicates on template parameters, evaluated at compile time. A concept may be associated with a template (class template, function template, member function of a class template, variable template, or alias template), in which case it serves as a constraint: it limits the set of arguments that are accepted as template parameters.
Originally dating back to suggestions for C++11, the original concepts specification has been revised multiple times before formally being standardised in C++20.
Main uses The main uses of concepts are:
introducing type-checking to template programming simplified compiler diagnostics for failed template instantiations selecting function template overloads and class template specializations based on type properties constraining automatic type deduction
Traditionally, template type restrictions were expressed using substitution failure is not an error (SFINAE), but concepts allow for a clearer expression of restrictions.
While a class may have only one destructor, a templated class may define multiple destructors through concepts. The compiler still chooses one destructor at compile-time based on the type constraint.
Constraint types and usage
There are five different places in a function template signature where a constraint can be used (labeled below from 1 through 5):
template <Concept1 T> requires Concept2<T> Concept3 auto myFunction(Concept4 auto param) requires Concept5<T>;
Concept1: A type-constraint. This kind replaces class or for declaring a template type parameter. When using a concept instead of the former two the type is constraint. Concept2: A requires-clause. Whenever a type-constraint does not work, for example, because the concept takes multiple parameters, a requires-clause can be used to apply more elaborated constraints. Concept3, Concept4: A constrained placeholder type. The same syntax is available for placeholder variable aka. auto variable. C++20 added abbreviated function templates which use auto as a placeholder type in the parameter declaration. A constrained placeholder type allows to put constraints on the automatically deduced return type of a function or a variable. Concept5: A trailing requires-clause. This form is similar to Concept2 with one notable exception. A trailing requires-clause can be applied to a function in a class template. This allows the function to remain a regular, template-free function, which can be enabled or disabled depending on the functions trailing requires-clause.
The constraint forms Concept1 and Concept2 can be used in all kinds of templates.
Examples Inheritance constraint The following demonstrates using a concept as an upper bound for inheritance constraints on types, by using std::derived_from<Derived, Base>.
import std;
using std::derived_from; using std::vector;
class Player { // ...
// T is required to be a type whose inheritance upper bound is Player, // blocking any type that does not inherit from Player template <derived_from<Player> T> void processListOfPlayers(const vector<T>& players) { // ... }
This is similar to constrained generics in Java, and is equivalent to the following example: import java.util.List;
class Player { // ... }
public class Example { // T is constrained to types that inherit from Player public static <T extends Player> void processListOfPlayers(List<T> players) { // ...
The following is a possible definition of the concept std::equality_comparable<T> from the <concepts> header of the C++ Standard Library. This concept is satisfied by any type T such that for lvalues a and b of type T, the expressions a == b and a != b as well as the reverse b == a and b != a compile, and their results are convertible to a type that satisfies the concept "boolean-testable":
/** * @namespace std * @brief The C++ Standard Library namespace */ namespace std { /** * @internal * @concept _WeaklyEqualityComparableWith * @brief The following concept is an implementation detail used to build equality_comparable * @tparam T the first template parameter to compare * @tparam U the second template parameter to compare */ template <typename T, typename U> concept _WeaklyEqualityComparableWith = requires (const remove_reference<T>& a, const remove_reference<U>& b) { { a == b } -> same_as<bool>; { a != b } -> same_as<bool>; { b == a } -> same_as<bool>; { b != a } -> same_as<bool>;
/** * @concept equality_comparable * @brief Checks that a == b, a != b, b == a, b != a compile and convert to bool * @tparam T the type to compare */ template <typename T> concept equality_comparable = _WeaklyEqualityComparableWith<T, T>; }
A function template constrained on this concept may be declared as follows:
// constrained abbreviated function template declaration // using a constrained placeholder type (Concept4 from above) void f(const equality_comparable auto& x);
or
// constrained function template declaration // using a type constraint (Concept1 from above) template <equality_comparable T> void f(const T& x);
And may be called as usual:
// OK, int satisfies equality_comparable f(42);
Type-safe variadic parameters C++ lacks type-safe variadic functions, like those of Java: void f(String... args), having only C-style , which lacks type safety. However, C++ does feature variadic templates, allowing for an indefinite number of template parameters.
To constrain the parameter to be only of type T (similar to T... args in Java), one can use the concept std::same_as or std::convertible_to (for types which may be intended to be convertible).
using std::same_as;
// Equivalent to Java declaration // <T> void fn(T... args) template <typename T> void fn(same_as<T> auto... args) { // ... }
This can be further constrained to any specific type: using std::convertible_to; using std::same_as; using std::string;
// Equivalent to Java declaration // void foo(int... args) void foo(same_as<int> auto... args) { // ... }
// Equivalent to Java declaration // void bar(String... args) void bar(convertible_to<string> auto... args) { // ... }
Interfaces
In object-oriented programming, an interface defines a set of method signatures which the class must implement in order to satisfy it. A concept may be seen as similar to an interface, which can define that a type satisfies various requirements.
import std;
using std::same_as; using std::floating_point;
template <typename T> concept Drawable = requires (T t) { { t.draw() } -> same_as<void>; // T::draw must return void { t.area() } -> floating_point; // matches any floating-point type
// The class Circle satisfies the Drawable concept // Circle does not need to declare it satisfies Drawable, however class Circle { private: const double radius; public: explicit Circle(double r): radius{r} {}
void draw() const { // draw a circle...
double area() const noexcept { return std::numbers::pi * radius * radius;
// Only types which satisfy Drawable may be used void render(const Drawable auto& shape) { // ... shape.draw(); std::println("Drew shape with area {}", shape.area()); }
Note that void render(const Drawable auto& shape); is equivalent to template <Drawable T> void render(const T& shape);; the former simply omits naming the template parameter.
This would be roughly similar to the following in Java: interface Drawable { void draw(); // must return void double area(); // must return double }
// Circle must explicitly declare that it implements Drawable class Circle implements Drawable { private final double radius;
public Circle(double r) { this.radius = r;
@Override public void draw() { // draw a circle...
@Override public double area() { return Math.PI * radius * radius;
// Only types which implement Drawable may be used static void render(Drawable shape) { // ... shape.draw(); System.out.printf("Drew shape with area %f", shape.area()); }
C++ concepts resemble Go interfaces very closely. Unlike Java interfaces, Go interfaces do not require a type to declare that it implements the interface, as types implicitly satisfy the interface as long as it implements all of its requirements. For example, this Drawable concept in C++ is roughly equivalent to the Go interface: import "math"
type Drawable interface { Draw() Area() float64 }
type Circle struct { radius float64 }
func (c Circle) Draw() { // draw a circle... }
func (c Circle) Area() float64 { return math.Pi * c.radius * c.radius }
Compiler diagnostics If a programmer attempts to use a template argument that does not satisfy the requirements of the template, the compiler will generate an error. When concepts are not used, such errors are often difficult to understand because the error is not reported in the context of the call, but rather in an internal, often deeply nested, implementation context where the type was used.
For example, std::sort() requires that its first two arguments be random-access iterators. If an argument is not an iterator, or is an iterator of a different category, an error will occur when std::sort() attempts to use its parameters as bidirectional iterators. Consider std::list<T>, which implements a doubly-linked list, and is not random-access:
using std::list;
// std::list is typically a doubly-linked list, whose iterators are not random-access list<int> l = {2, 1, 3}; std::sort(l.begin(), l.end());
Typical compiler diagnostic without concepts is over 50 lines of output, beginning with a failure to compile an expression that attempts to subtract two iterators:
In instantiation of 'void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = std::_List_iterator<int>; _Compare = __gnu_cxx::__ops::_Iter_less_iter]': error: no match for 'operator-' (operand types are 'std::_List_iterator<int>' and 'std::_List_iterator<int>') std::__lg(__last - __first) * 2,
[..]
If concepts are used, the error can be detected and reported in the context of the call:
error: cannot call function 'void std::sort(_RAIter, _RAIter) [with _RAIter = std::_List_iterator<int>]' note: concept 'RandomAccessIterator()' was not satisfied
Overload resolution Concepts can be used to choose function template overloads and class template specializations based on properties of their template arguments, as an alternative to SFINAE and tag dispatching. If an argument satisfies more than one concept, the overload associated with the more constrained concept is chosen.
Type deduction Concepts may be used instead of the unconstrained type deduction placeholder in variable declarations and function return types:
auto x1 = f(y); // the type of x1 is deduced to whatever f returns Sortable auto x2 = f(y); // the type of x2 is deduced, but only compiles if it satisfies Sortable
Implementation status Concepts TS, as specified in ISO/IEC TS 19217:2015, are implemented as an experimental feature in GCC 6. C++20 concepts are fully implemented in GCC 10, MSVC 19.30, and Clang 10.
History A different form of Concepts, popularly known as "C++0x Concepts", was temporarily accepted into the working paper for C++11 but was removed in 2009. In addition to concepts themselves, "C++0x Concepts" included concept maps (a feature that could make it possible, for example, for the concept Stack to accept std::vector<T>, automatically mapping Stack operations such as push() to differently named operations on std::vector<T>, such as push_back() and axioms (a facility to specify semantic properties such as associativity or commutativity, allowing the compiler to take advantage of these properties without proof). The proposed syntax looked something like the following: template <ValueType T> concept_map ForwardIterator<T*> { typedef T value_type;
concept TotalOrder<typename Operator, typename T> { axiom Transitivity(Operator op, T x, T y, T z) {