Objects, references, functions including function template specializations, and expressions have a property called type, which both restricts the operations that are permitted for those entities and provides semantic meaning to the otherwise generic sequences of bits.
The C++ type system consists of the following types:
std::is_fundamental): std::is_void);
| (since C++11) |
std::is_arithmetic): std::is_integral):
| (since C++20) |
char16_t, char32_t, (since C++11)wchar_t;
| (since C++11) |
| (since C++11) |
std::is_floating_point):
| (since C++23) |
std::is_compound): std::is_reference): std::is_lvalue_reference):
| (since C++11) |
std::is_pointer): std::is_member_pointer): std::is_member_object_pointer); std::is_member_function_pointer); std::is_array); std::is_function); std::is_enum);
| (since C++11) |
std::is_class); std::is_union). signed char and unsigned char are narrow character types, but they are not character types. In other words, the set of narrow character types is not a subset of the set of character types. For every non-cv-qualified type other than reference and function, the type system supports three additional cv-qualified versions of that type (const, volatile, and const volatile).
Types are grouped in various categories based on their properties:
std::is_object); std::is_scalar); std::is_trivial), POD types (see also std::is_pod), literal types (see also std::is_literal_type), and other categories listed in the type traits library or as named type requirements. Constructing a complete object type such that the number of bytes in its object representation is not representable in the type std::size_t (i.e. the result type of sizeof operator) is ill-formed.
A name can be declared to refer to a type by means of:
Types that do not have names often need to be referred to in C++ programs; the syntax for that is known as type-id. The syntax of the type-id that names type T is exactly the syntax of a declaration of a variable or function of type T, with the identifier omitted, except that decl-specifier-seq of the declaration grammar is constrained to type-specifier-seq, and that new types may be defined only if the type-id appears on the right-hand side of a non-template type alias declaration.
int* p; // declaration of a pointer to int
static_cast<int*>(p); // type-id is "int*"
int a[3]; // declaration of an array of 3 int
new int[3]; // type-id is "int[3]" (called new-type-id)
int (*(*x[2])())[3]; // declaration of an array of 2 pointers to functions
// returning pointer to array of 3 int
new (int (*(*[2])())[3]); // type-id is "int (*(*[2])())[3]"
void f(int); // declaration of a function taking int and returning void
std::function<void(int)> x = f; // type template parameter is a type-id "void(int)"
std::function<auto(int) -> void> y = f; // same
std::vector<int> v; // declaration of a vector of int
sizeof(std::vector<int>); // type-id is "std::vector<int>"
struct { int x; } b; // creates a new type and declares an object b of that type
sizeof(struct { int x; }); // error: cannot define new types in a sizeof expression
using t = struct { int x; }; // creates a new type and declares t as an alias of that type
sizeof(static int); // error: storage class specifiers not part of type-specifier-seq
std::function<inline void(int)> f; // error: neither are function specifiersThe declarator part of the declaration grammar with the name removed is referred to as abstract-declarator.
Type-id may be used in the following situations:
| (until C++17) |
Type-id can be used with some modifications in the following situations:
Elaborated type specifiers may be used to refer to a previously-declared class name (class, struct, or union) or to a previously-declared enum name even if the name was hidden by a non-type declaration. They may also be used to declare new class names.
See elaborated type specifier for details.
The type of an expression that results from the compile-time analysis of the program is known as the static type of the expression. The static type does not change while the program is executing.
If some glvalue expression refers to a polymorphic object, the type of its most derived object is known as the dynamic type.
// given
struct B { virtual ~B() {} }; // polymorphic type
struct D : B {}; // polymorphic type
D d; // most-derived object
B* ptr = &d;
// the static type of (*ptr) is B
// the dynamic type of (*ptr) is DFor prvalue expressions, the dynamic type is always the same as the static type.
The following types are incomplete types:
All other types are complete.
Any of the following contexts requires type T to be complete:
T or argument type T; T; T; T or an array whose element type is T; T; T; T* or T&, except when converting from the null pointer constant or from a pointer to possibly cv-qualified void; T; T; T; T; T; T, T&, or T*. (In general, when the size and layout of T must be known.).
If any of these situations occur in a translation unit, the definition of the type must appear in the same translation unit. Otherwise, it is not required.
An incompletely-defined object type can be completed:
struct X; // declaration of X, no definition provided yet
extern X* xp; // xp is a pointer to an incomplete type:
// the definition of X is not reachable
void foo()
{
xp++; // ill-formed: X is incomplete
}
struct X { int i; }; // definition of X
X x; // OK: the definition of X is reachable
void bar()
{
xp = &x; // OK: type is “pointer to X”
xp++; // OK: X is complete
}T" and "array of N T") are different types. The type of a pointer or reference to array of unknown bound permanently points to or refers to an incomplete type. An array of unknown bound named by a typedef declaration permanently refers to an incomplete type. In either case, the array type cannot be completed:
extern int arr[]; // the type of arr is incomplete
typedef int UNKA[]; // UNKA is an incomplete type
UNKA* arrp; // arrp is a pointer to an incomplete type
UNKA** arrpp;
void foo()
{
arrp++; // error: UNKA is an incomplete type
arrpp++; // OK: sizeof UNKA* is known
}
int arr[10]; // now the type of arr is complete
void bar()
{
arrp = &arr; // error: different types
arrp++; // error: UNKA cannot be completed
}The following behavior-changing defect reports were applied retroactively to previously published C++ standards.
| DR | Applied to | Behavior as published | Correct behavior |
|---|---|---|---|
| CWG 328 | C++98 | class members of incomplete type were not prohibited if an object of the class type was never created | non-static class data members need to be complete |
| CWG 977 | C++98 | the point when an enumeration type becomes complete in its definition was unclear | the type is complete once the underlying type is determined |
| CWG 1362 | C++98 | user-defined conversions to type T* or T& required T to be complete | not required |
| CWG 1464 | C++98 | object size might be not representable in std::size_t | such type is ill-formed |
| CWG 2006 | C++98 | cv-qualified void types were object type and complete type | excluded from both categories |
| CWG 2448 | C++98 | only cv-unqualified types could be integral and floating-point types | allowed cv-qualified types |
| CWG 2630 | C++98 | it was unclear whether a class is considered complete outside the translation unit where the definition of the class appears | the class is complete if its definition is reachable in this case |
| CWG 2643 | C++98 | the type of a pointer to array of unknown bound could not be completed (but it is already complete) | the pointed-to array type cannot be completed |
| C documentation for Type |
© cppreference.com
Licensed under the Creative Commons Attribution-ShareAlike Unported License v3.0.
https://en.cppreference.com/w/cpp/language/type