Named Requirements
From cppreference.com
< cpp
The named requirements listed on this page are the named requirements used in the normative text of the C++ standard to define the expectations of the standard library.
The burden to ensure that library templates are instantiated with template arguments that satisfy these requirements is on the programmer. Failure to do so may result in very complex compiler diagnostics.
Some of these requirements are formalized in C++20 using the concepts language feature.
Basic | ||
| specifies that an object of the type can be default constructed (named requirement) | ||
| (C++11) |
specifies that an object of the type can be constructed from rvalue (named requirement) | |
| specifies that an object of the type can be constructed from lvalue (named requirement) | ||
| (C++11) |
specifies that an object of the type can be assigned from rvalue (named requirement) | |
| specifies that an object of the type can be assigned from lvalue (named requirement) | ||
| specifies that an object of the type can be destroyed (named requirement) | ||
Type properties | ||
| Note: the standard does not define named requirements with names specified in this subcategory. These are type categories defined by the core language. They are included here as named requirements only for consistency. | ||
| object types that are not array types or class types (named requirement) | ||
| (deprecated in C++20) |
POD (Plain Old Data) types, compatible with C struct (named requirement) | |
| (C++11) |
objects of these types can maintain their values after copying their underlying bytes (named requirement) | |
| (C++11)(deprecated in C++26) |
objects of these types can be trivially constructed and copied (named requirement) | |
| (C++11) |
these types are useful for communicating with code written in other programming languages (named requirement) | |
| objects of these types can be implicitly created, and their lifetimes can be implicitly started (named requirement) | ||
Library-wide | ||
| boolean operations (operator&&, operator||, and operator!) have usual semantics (named requirement) | ||
operator== is an equivalence relation(named requirement) | ||
| | ||