Namespaces
Variants
Views
Actions

Difference between revisions of "cpp/language/definition"

From cppreference.com
< cpp‎ | language
(ODR-use: fix)
(Links to the definition of “potentially-invoked destructor”.)
 
(38 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{title|Definitions and ODR}}
+
{{title|Definitions and ODR (One Definition Rule)}}
 
{{cpp/language/basics/navbar}}
 
{{cpp/language/basics/navbar}}
 
''Definitions'' are {{rlp|declarations}} that fully define the entity introduced by the declaration. Every declaration is a definition, except for the following:
 
''Definitions'' are {{rlp|declarations}} that fully define the entity introduced by the declaration. Every declaration is a definition, except for the following:
  
* A function declaration without a function body
+
* A function declaration without a function body:
 
{{source|int f(int); // declares, but doesn't define f}}
 
{{source|int f(int); // declares, but doesn't define f}}
* Any declaration with an {{c|extern}} {{rlp|storage_duration|storage class specifier}} or with a {{rlp|language linkage}} specifier (such as {{c|extern "C"}}) without an initializer
+
* Any declaration with an {{c|extern}} {{rlp|storage duration|storage class specifier}} or with a {{rlp|language linkage}} specifier (such as {{c|extern "C"}}) without an initializer:
 
{{source|1=
 
{{source|1=
extern const int a; // declares, but doesn't define a
+
extern const int a;     // declares, but doesn't define a
 
extern const int b = 1; // defines b
 
extern const int b = 1; // defines b
 
}}
 
}}
* Declaration of a {{rev inl|since=c++17|non-inline}} {{rlp|static|static data member}} inside a class definition
+
* Declaration of a {{rev inl|since=c++17|non-inline}} {{rlp|static|static data member}} inside a class definition:
 
{{source|
 
{{source|
struct S {
+
struct S
 +
{
 
     int n;              // defines S::n
 
     int n;              // defines S::n
 
     static int i;        // declares, but doesn't define S::i
 
     static int i;        // declares, but doesn't define S::i
 
     inline static int x; // defines S::x
 
     inline static int x; // defines S::x
 
};                      // defines S
 
};                      // defines S
 +
 
int S::i;                // defines S::i
 
int S::i;                // defines S::i
 
}}
 
}}
{{rev begin}}
+
{{rrev|since=c++17|
{{rev | since=c++17 |
+
* {{mark deprecated}} Namespace scope declaration of a static data member that was defined within the class with the {{tt|{{rlp|constexpr}}}} specifier:
* {{mark deprecated}} Namespace scope declaration of a static data member that was defined within the class with the {{tt|{{rlp|constexpr}}}} specifier
+
 
{{source|1=
 
{{source|1=
struct S {
+
struct S
 +
{
 
     static constexpr int x = 42; // implicitly inline, defines S::x
 
     static constexpr int x = 42; // implicitly inline, defines S::x
 
};
 
};
 +
 
constexpr int S::x; // declares S::x, not a redefinition
 
constexpr int S::x; // declares S::x, not a redefinition
 
}}
 
}}
 
}}
 
}}
{{rev end}}
+
* Declaration of a class name (by {{rlpsd|class#Forward declaration}} or by the use of the elaborated type specifier in another declaration):
* Declaration of a class name (by {{rlp|class#Forward declaration|forward declaration}} or by the use of the elaborated type specifier in another declaration)
+
 
{{source|
 
{{source|
struct S; // declares, but doesn't define S
+
struct S;             // declares, but doesn't define S
 +
 
 
class Y f(class T p); // declares, but doesn't define Y and T (and also f and p)
 
class Y f(class T p); // declares, but doesn't define Y and T (and also f and p)
 
}}
 
}}
{{rev begin}}
+
{{rrev|since=c++11|
{{rev|since=c++11|
+
* An {{rlp|enum|opaque declaration}} of an enumeration:
* An {{rlp|enum|opaque declaration}} of an enumeration
+
 
{{source|
 
{{source|
 
enum Color : int; // declares, but doesn't define Color
 
enum Color : int; // declares, but doesn't define Color
 
}}
 
}}
 
}}
 
}}
{{rev end}}
+
* Declaration of a {{rlp|template parameters|template parameter}}:
* Declaration of a {{rlp|template parameters|template parameter}}
+
 
{{source|
 
{{source|
 
template<typename T> // declares, but doesn't define T
 
template<typename T> // declares, but doesn't define T
 
}}
 
}}
* A parameter declaration in a function declaration that isn't a definition
+
* A parameter declaration in a function declaration that isn't a definition:
 
{{source|
 
{{source|
 
int f(int x); // declares, but doesn't define f and x
 
int f(int x); // declares, but doesn't define f and x
int f(int x) { // defines f and x
+
 
    return x+a;
+
int f(int x) // defines f and x
 +
{
 +
    return x + a;
 
}
 
}
 
}}
 
}}
* A {{rlp|typedef}} declaration
+
* A {{rlp|typedef}} declaration:
 
{{source|1=
 
{{source|1=
 
typedef S S2; // declares, but doesn't define S2 (S may be incomplete)
 
typedef S S2; // declares, but doesn't define S2 (S may be incomplete)
 
}}
 
}}
{{rev begin}}
+
{{rrev|since=c++11|
{{rev|since=c++11|
+
* An {{rlp|type alias|alias-declaration}}:
* An {{rlp|type alias|alias-declaration}}
+
 
{{source|1=
 
{{source|1=
 
using S2 = S; // declares, but doesn't define S2 (S may be incomplete)
 
using S2 = S; // declares, but doesn't define S2 (S may be incomplete)
 
}}
 
}}
 
}}
 
}}
{{rev end}}
+
* A {{rlp|using declaration|using-declaration}}:
* A {{rlp|using declaration|using-declaration}}
+
 
{{source|1=
 
{{source|1=
 
using N::d; // declares, but doesn't define d
 
using N::d; // declares, but doesn't define d
Line 72: Line 73:
 
{{rev begin}}
 
{{rev begin}}
 
{{rev|since=c++17|
 
{{rev|since=c++17|
* Declaration of a {{rlp|class template argument deduction#Explicit_deduction_guides|deduction guide}} (does not define any entities)
+
* Declaration of a {{rlp|class template argument deduction#Explicit deduction guides|deduction guide}} (does not define any entities)
 
}}
 
}}
 
{{rev|since=c++11|
 
{{rev|since=c++11|
Line 81: Line 82:
 
* An {{rlp|declarations|empty declaration}} (does not define any entities)
 
* An {{rlp|declarations|empty declaration}} (does not define any entities)
 
* A {{rlp|namespace#Using-directives|using-directive}} (does not define any entities)
 
* A {{rlp|namespace#Using-directives|using-directive}} (does not define any entities)
{{rev begin}}
+
{{rrev|since=c++11|
{{rev|since=c++11|
+
* An {{rlp|class template#Class template instantiation|explicit instantiation declaration}} (an "extern template"):
* An {{rlp|class_template#Class_template_instantiation|explicit instantiation declaration}} (an "extern template")
+
 
{{source|1=
 
{{source|1=
extern template f<int, char>; // declares, but doesn't define f<int, char>
+
extern template
 +
f<int, char>; // declares, but doesn't define f<int, char>
 
}}
 
}}
 
}}
 
}}
{{rev end}}
+
* An {{rlp|template specialization|explicit specialization}} whose declaration is not a definition:
* An {{rlp|template specialization|explicit specialization}} whose declaration is not a definition.
+
 
{{source|1=
 
{{source|1=
template<> struct A<int>; // declares, but doesn't define A<int>
+
template<>
 +
struct A<int>; // declares, but doesn't define A<int>
 
}}
 
}}
  
 
An {{rlp|asm|asm declaration}} does not define any entities, but it is classified as a definition.
 
An {{rlp|asm|asm declaration}} does not define any entities, but it is classified as a definition.
  
Where necessary, the compiler may implicitly define the {{rlp|default constructor}}, {{rlp|copy constructor}}, {{rlp|move constructor}}, {{rlp|as_operator|copy assignment operator}}, {{rlp|move_operator|move assignment operator}}, and the {{rlp|destructor}}.
+
Where necessary, the compiler may implicitly define the {{rlp|default constructor}}, {{rlp|copy constructor}}, {{rlp|move constructor}}, {{rlp|as operator|copy assignment operator}}, {{rlp|move operator|move assignment operator}}, and the {{rlp|destructor}}.
  
 
If the definition of any object results in an object of {{rlp|incomplete type}} or {{rlp|abstract class|abstract class type}}, the program is ill-formed.
 
If the definition of any object results in an object of {{rlp|incomplete type}} or {{rlp|abstract class|abstract class type}}, the program is ill-formed.
Line 102: Line 103:
 
{{anchor|ODR}}
 
{{anchor|ODR}}
 
===One Definition Rule===
 
===One Definition Rule===
Only one definition of any variable, function, class type, enumeration type, {{rev inl|since=c++20|{{rlp|constraints|concept}}}} or template is allowed in any one translation unit (some of these may have multiple declarations, but only one definition is allowed).
+
Only one definition of any variable, function, class type, enumeration type{{rev inl|since=c++20|{{rlp|constraints|, concept}}}} or template is allowed in any one translation unit (some of these may have multiple declarations, but only one definition is allowed).
  
 
One and only one definition of every non-{{rlp|inline}} function or variable that is ''odr-used'' (see below) is required to appear in the entire program (including any standard and user-defined libraries). The compiler is not required to diagnose this violation, but the behavior of the program that violates it is undefined.
 
One and only one definition of every non-{{rlp|inline}} function or variable that is ''odr-used'' (see below) is required to appear in the entire program (including any standard and user-defined libraries). The compiler is not required to diagnose this violation, but the behavior of the program that violates it is undefined.
  
For an inline function {{rev inl|since=c++17|or inline variable}}, a definition is required in every translation unit where it is ''odr-used''.
+
For an inline function{{rev inl|since=c++17| or inline variable}}, a definition is required in every translation unit where it is ''odr-used''.
  
One and only one definition of a class is required to appear in any translation unit where the class is used in a way that requires it to be {{rlp|incomplete type|complete}}.
+
For a class, a definition is required wherever the class is used in a way that requires it to be {{rlp|incomplete type|complete}}.
 +
 
 +
There can be more than one definition in a program of each of the following: class type, enumeration type, inline function{{rev inl|since=c++17|, inline variable}}, {{rlpsd|templates#Templated entity}} (template or member of template, but not full {{rlp|template specialization}}), as long as all of the following is true:
 +
* each definition appears in a different translation unit
 +
{{rrev|since=c++20|
 +
* the definitions are not {{rlp|modules|attached to a named module}}
 +
}}
  
There can be more than one definition in a program, as long as each definition appears in a different translation unit, of each of the following: class type, enumeration type, inline function with external linkage {{rev inl|since=c++17|inline variable with external linkage}}, class template, non-static function template, static data member of a class template, member function of a class template, partial template specialization, {{rev inl|since=c++20|{{rlp|constraints|concept}},}} as long as all of the following is true:
 
 
* each definition consists of the same sequence of tokens (typically, appears in the same header file)
 
* each definition consists of the same sequence of tokens (typically, appears in the same header file)
* name lookup from within each definition finds the same entities (after overload-resolution), except that constants with internal or no linkage may refer to different objects as long as they are not ODR-used and have the same values in every definition.
+
* name lookup from within each definition finds the same entities (after overload-resolution), except that
 +
:* constants with internal or no linkage may refer to different objects as long as they are not odr-used and have the same values in every definition
 +
{{rrev|since=c++11|
 +
:* lambda-expressions that are not in a default argument{{rev inl|since=c++20| or a default template argument}} are uniquely identified by the sequence of tokens used to define them
 +
}}
 
* overloaded operators, including conversion, allocation, and deallocation functions refer to the same function from each definition (unless referring to one defined within the definition)
 
* overloaded operators, including conversion, allocation, and deallocation functions refer to the same function from each definition (unless referring to one defined within the definition)
* the language linkage is the same (e.g. the include file isn't inside an extern "C" block)
+
* corresponding entities have the same language linkage in each definition (e.g. the include file isn't inside an extern "C" block)
* the three rules above apply to every default argument used in each definition
+
* if a {{tt|const}} object is {{rlp|constant initialization|constant-initialized}} in any of the definitions, it is constant-initialized in each definition
 +
* the rules above apply to every default argument used in each definition
 +
* if the definition is for a class with an implicitly-declared constructor, every translation unit where it is odr-used must call the same constructor for the base and members
 
{{rrev|since=c++20|
 
{{rrev|since=c++20|
* if the definition invokes a function with a precondition ({{attr|contract|expects:}}) or is a function that contains an assertion ({{attr|contract|assert:}}) or has a contract condition ({{attr|contract|expects:}} or {{attr|contract|ensures:}}), it is implementation-defined under which conditions all definitions must be translated using the same build level and violation continuation mode
+
* if the definition is for a class with a defaulted {{rlp|default comparisons|three-way comparison}}, every translation unit where it is odr-used must call the same comparison operator for the base and members
 
}}
 
}}
* if the definition is for a class with an implicitly-declared constructor, every translation unit where it is odr-used must call the same constructor for the base and members
+
 
 
* if the definition is for a template, then all these requirements apply to both names at the point of definition and dependent names at the point of instantiation
 
* if the definition is for a template, then all these requirements apply to both names at the point of definition and dependent names at the point of instantiation
  
If all these requirements are satisfied, the program behaves as if there is only one definition in the entire program. Otherwise, the behavior is undefined.  
+
If all these requirements are satisfied, the program behaves as if there is only one definition in the entire program. Otherwise, the program is ill-formed, no diagnostic required.
  
Note: in C, there is no program-wide ODR for types, and even extern declarations of the same variable in different translation units may have different types [[c/language/type#Compatible_types|as long as they are compatible]]. In C++, the source-code tokens used in declarations of the same type must be the same as described above: if one .cpp file defines {{tt|struct S { int x; };}} and the other .cpp file defines {{tt|struct S { int y; };}}, the behavior of the program that links them together is undefined. This is usually resolved with {{rlp|namespace|unnamed namespaces}}.
+
Note: in C, there is no program-wide ODR for types, and even extern declarations of the same variable in different translation units may have different types [[c/language/type#Compatible types|as long as they are compatible]]. In C++, the source-code tokens used in declarations of the same type must be the same as described above: if one .cpp file defines {{c|struct S { int x; };}} and the other .cpp file defines {{c|struct S { int y; };}}, the behavior of the program that links them together is undefined. This is usually resolved with {{rlp|namespace|unnamed namespaces}}.
  
 
====ODR-use====
 
====ODR-use====
 
+
Informally,
Informally, an object is odr-used if its value is read (unless it is a compile time constant) or written, its address is taken, or a reference is bound to it; a reference is odr-used if it is used and its referent is not known at compile time; and a function is odr-used if a function call to it is made or its address is taken. If an object, a reference or a function is odr-used, its definition must exist somewhere in the program; a violation of that is usually a link-time error.
+
* an object is odr-used if its value is read (unless it is a compile time constant) or written, its address is taken, or a reference is bound to it,
 +
* a reference is odr-used if it is used and its referent is not known at compile time,
 +
* a function is odr-used if a function call to it is made or its address is taken.
 +
If an object, a reference or a function is odr-used, its definition must exist somewhere in the program; a violation of that is usually a link-time error.
  
 
{{source|1=
 
{{source|1=
struct S {
+
struct S
 +
{
 
     static const int x = 0; // static data member
 
     static const int x = 0; // static data member
 
     // a definition outside of class is required if it is odr-used
 
     // a definition outside of class is required if it is odr-used
 
};
 
};
 +
 
const int& f(const int& r);
 
const int& f(const int& r);
  
Line 142: Line 159:
  
 
Formally,
 
Formally,
@1@ a variable {{tt|x}} in a ''potentially-evaluated'' expression {{tt|ex}} is odr-used unless both of the following are true:
+
@1@ a variable {{c|x}} in a {{rlp|expressions#Potentially-evaluated expressions|potentially-evaluated expression}} {{c|ex}} is odr-used unless both of the following are true:
:* applying lvalue-to-rvalue conversion to {{tt|x}} yields a constant expression that doesn't invoke non-trivial functions
+
* applying lvalue-to-rvalue conversion to {{c|x}} yields a constant expression that doesn't invoke non-trivial functions
:* either {{tt|x}} is not an object (that is, {{tt|x}} is a reference) or, if {{tt|x}} is an object, it is one of the ''potential results'' of a larger expression {{tt|e}}, where that larger expression is either a {{rlp|expressions#Discarded-value_expressions|discarded-value expression}} or has the lvalue-to-rvalue conversion applied to it
+
* either {{c|x}} is not an object (that is, {{c|x}} is a reference) or, if {{c|x}} is an object, it is one of the ''potential results'' of a larger expression {{c|e}}, where that larger expression is either a {{rlp|expressions#Discarded-value expressions|discarded-value expression}} or has the lvalue-to-rvalue conversion applied to it
 
{{source|1=
 
{{source|1=
struct S { static const int x = 1; }; // applying lvalue-to-rvalue conversion to S::x yields a constant expression
+
struct S { static const int x = 1; }; // applying lvalue-to-rvalue conversion
int f() {  
+
                                      // to S::x yields a constant expression
 +
 
 +
int f()
 +
{
 
     S::x;        // discarded-value expression does not odr-use S::x
 
     S::x;        // discarded-value expression does not odr-use S::x
     return S::x; // expression where lvalue-to-rvalue conversion applies does not odr-use S::x
+
   
 +
     return S::x; // expression where lvalue-to-rvalue conversion
 +
                // applies does not odr-use S::x
 
}
 
}
 
}}
 
}}
@2@ {{rlp|this|{{tt|*this}}}} is odr-used if {{c|this}} appears as a ''potentially-evaluated'' expression (including the implicit {{c|this}} in a non-static member function call expression)
+
@2@ {{c|*this}} is odr-used if {{c|this}} appears as a potentially-evaluated expression (including the implicit {{c|this}} in a non-static member function call expression)
  
 
{{rrev|since=c++17|1=
 
{{rrev|since=c++17|1=
@3@ A {{rlp|structured binding}} is odr-used if it appears as a ''potentially-evaluated'' expression.<!---P0588R1-->
+
@3@ A {{rlp|structured binding}} is odr-used if it appears as a potentially-evaluated expression.<!---P0588R1-->
 
}}
 
}}
In the definitions above, ''potentially-evaluated'' means the expression is not an {{rlp|expressions#Unevaluated expressions|unevaluated operand}} (or its subexpression), such as the operand of {{rlp|sizeof}} and ''a set of potential results'' of an expression {{tt|e}} is a (possibly empty) set of id-expressions that appear within {{tt|e}}, combined as follows:
+
A set of ''potential results'' of an expression {{c|E}} is a (possibly empty) set of id-expressions that appear within {{c|E}}, combined as follows:
* If {{tt|e}} is an {{rlp|expressions|id-expression}}, the expression {{tt|e}} is its only potential result
+
* If {{c|E}} is an {{rlp|expressions#Primary expressions|id-expression}}, the expression {{c|E}} is its only potential result.
{{rev begin}}
+
* If {{c|E}} is a subscript expression ({{c|E1[E2]}}) where one of the operands is an array, the potential results of that operand is included in the set.
{{rev|since=c++17|
+
* If {{c|E}} is a class member access expression of the form {{c|E1.E2}} or {{c|E1.template E2}} naming a non-static data member, the potential results of {{c|E1}} is included in the set.
* If {{tt|e}} is an array subscript expression ({{c|e1[e2]}}) where one of the operands is an array, the potential results of that operand is included in the set}}
+
* If {{c|E}} is a class member access expression naming a static data member, the id-expression designating the data member is included in the set.
{{rev end}}
+
* If {{c|E}} is a pointer-to-member access expression of the form {{c|E1.*E2}} or {{c|E1.*template E2}} whose second operand is a constant expression, the potential results of {{c|E1}} are included in the set.
* If {{tt|e}} is a class member access expression ({{c|e1.e2}} or {{c|e1->e2}}), the potential results of the object expression e1 is included in the set.
+
* If {{c|E}} is an expression in parentheses ({{c|(E1)}}), the potential results of {{c|E1}} are included in the set.
* If {{tt|e}} is a pointer-to-member access expression ({{c|e1.*e2}} or {{c|e1->*e2}}) whose second operand is a constant expression, the potential results of the object expression e1 are included in the set
+
* If {{c|E}} is a glvalue conditional expression ({{c|E1 ? E2 : E3}}, where {{c|E2}} and {{c|E3}} are glvalues), the union of the potential results of {{c|E2}} and {{c|E3}} are both included in the set.
* If {{tt|e}} is an expression in parentheses ({{c|(e1)}}), the potential results of {{tt|e1}} are included in the set
+
* If {{c|E}} is a comma expression ({{c|E1, E2}}), the potential results of {{c|E2}} are in the set of potential results.
* If {{tt|e}} is a glvalue conditional expression ({{c|e1?e2:e3}}, where e2 and e3 are glvalues), the union of the potential results of {{tt|e2}} and {{tt|e3}} are both included in the set.
+
* If {{tt|e}} is a comma expression ({{c|e1,e2}}), the potential results of {{tt|e2}} are in the set of potential results
+
 
* Otherwise, the set is empty.
 
* Otherwise, the set is empty.
 
{{source|1=
 
{{source|1=
struct S {
+
struct S
  static const int a = 1;
+
{
  static const int b = 2;
+
    static const int a = 1;
 +
    static const int b = 2;
 
};
 
};
int f(bool x) {
+
 
  return x ? S::a : S::b;
+
int f(bool x)
  // x is a part of the subexpression "x" (to the left of ?),
+
{
  // which applies lvalue-to-rvalue conversion, but applying that conversion to x
+
    return x ? S::a : S::b;
  // does not yield a constant expression, so x is odr-used
+
    // x is a part of the subexpression "x" (to the left of ?),
  // S::a and S::b are lvalues, and carry over as "potential results" to the result
+
    // which applies lvalue-to-rvalue conversion, but applying that conversion to x
  // of the glvalue conditional
+
    // does not yield a constant expression, so x is odr-used
  // That result is then subject to lvalue-to-rvalue conversion requested
+
    // S::a and S::b are lvalues, and carry over as "potential results"
  // to copy-initialize the return value, therefore S::a and S::b are not odr-used
+
    // to the result of the glvalue conditional
 +
    // That result is then subject to lvalue-to-rvalue conversion requested
 +
    // to copy-initialize the return value, therefore S::a and S::b are not odr-used
 
}
 
}
 
}}
 
}}
  
@4@ Functions are ODR-used if
+
@4@ A function is odr-used in following cases:
* A function whose name appears as a potentially-evaluated expression (including named function, overloaded operator, {{rlp|cast operator|user-defined conversion}}, user-defined placement forms of operator new, non-default initialization)  is odr-used if it is selected by overload resolution, except when it is an unqualified pure virtual member function {{rev inl|since=c++17|or a pointer-to-member to a pure virtual function}}.
+
* A function is odr-used if it is named by (see below) a potentially-evaluated expression or conversion.
* {{rlp|virtual|virtual member function}} is odr-used if it is not a pure virtual member function (addresses of virtual member functions are required to construct the vtable)
+
* A {{rlp|virtual|virtual member function}} is odr-used if it is not a pure virtual member function (addresses of virtual member functions are required to construct the vtable).
* An [[cpp/memory/new/operator_new|allocation]] or deallocation function for a class is odr-used by a {{rlp|new|new expression}} appearing in a potentially-evaluated expression
+
* A deallocation function for a class is odr-used by a {{rlp|delete|delete expression}} appearing in a potentially-evaluated expression
+
 
* A non-placement allocation or deallocation function for a class is odr-used by the definition of a constructor of that class.
 
* A non-placement allocation or deallocation function for a class is odr-used by the definition of a constructor of that class.
* A non-placement deallocation function for a class is odr-used by the definition of the destructor of that class, or by being selected by the lookup at the point of definition of a virtual destructor
+
* A non-placement deallocation function for a class is odr-used by the definition of the destructor of that class, or by being selected by the lookup at the point of definition of a virtual destructor.
 
* An assignment operator in a class {{tt|T}} that is a member or base of another class {{tt|U}} is odr-used by an implicitly-defined copy-assignment or move-assignment functions of {{tt|U}}.
 
* An assignment operator in a class {{tt|T}} that is a member or base of another class {{tt|U}} is odr-used by an implicitly-defined copy-assignment or move-assignment functions of {{tt|U}}.
 
* A constructor (including default constructors) for a class is odr-used by the {{rlp|initialization}} that selects it.
 
* A constructor (including default constructors) for a class is odr-used by the {{rlp|initialization}} that selects it.
* A destructor for a class is odr-used if it is potentially invoked
+
* A destructor for a class is odr-used if it is {{rlp|destructor#Potentially-invoked destructor|potentially invoked}}.
 
+
In all cases, a constructor selected to copy or move an object is odr-used even if {{rlp|copy elision}} takes place.
+
  
 
{{todo|list of all situations where odr-use makes a difference}}
 
{{todo|list of all situations where odr-use makes a difference}}
 +
 +
====Naming a function====
 +
A function is named by an expression or conversion in following cases:
 +
* A function whose name appears as an expression or conversion (including named function, overloaded operator, {{rlp|cast operator|user-defined conversion}}, user-defined placement forms of {{ltt|cpp/memory/new/operator new}}, non-default initialization) is named by that expression if it is selected by overload resolution, except when it is an unqualified pure virtual member function or a pointer-to-member to a pure virtual function.
 +
* An [[cpp/memory/new/operator new|allocation]] or [[cpp/memory/new/operator delete|deallocation]] function for a class is named by a {{rlp|new|new expression}} appearing in an expression.
 +
* A deallocation function for a class is named by a {{rlp|delete|delete expression}} appearing in an expression.
 +
* A constructor selected to copy or move an object is considered to be named by the expression or conversion even if {{rlp|copy elision}} takes place. {{rev inl|since=c++17|Using a prvalue in some contexts does not copy or move an object, see {{rlp|copy elision#Mandatory elision of copy/move operations|mandatory elision}}.}}
 +
 +
A potentially evaluated expression or conversion odr-uses a function if it names it.
 +
{{rrev|since=c++11|<!-- P0859R0 -->
 +
A potentially constant evaluated expression or conversion that names a constexpr function makes it {{rlp|constant expression#Functions and variables needed for constant evaluation|needed for constant evaluation}}, which triggers definition of a defaulted function or instantiation of a function template specialization, even if the expression is unevaluated.
 +
}}
 +
 +
===Defect reports===
 +
{{dr list begin}}
 +
{{dr list item|wg=cwg|dr=261|std=C++98|before=a deallocation function for a polymorphic class<br>might be odr-used even if there were no relevant<br>new or delete expressions in the program|after=supplemented the<br>odr-use cases to cover<br>constructors and destructors}}
 +
{{dr list item|wg=cwg|dr=678|std=C++98|before=an entity could have definitions<br>with different language linkages|after=the behavior is<br>undefined in this case}}
 +
{{dr list item|wg=cwg|dr=1472|std=C++98|before=reference variables which satisfy the requirements for<br>appearing in a constant expression were odr-used even<br>if the lvalue-to-rvalue conversion is immediately applied|after=they are not odr-used<br>in this case}}
 +
{{dr list item|wg=cwg|dr=1614|std=C++98|before=taking address of a pure virtual function odr-used it|after=the function is not odr-used}}
 +
{{dr list item|wg=cwg|dr=1741|std=C++98|before=constant objects that are immediately lvalue-to-rvalue<br>converted in potentially-evaluated expressions were odr-used|after=they are not odr-used}}
 +
{{dr list item|wg=cwg|dr=1926|std=C++98|before=array subscript expressions didn't propagate potential results|after=they propagate}}
 +
{{dr list item|wg=cwg|dr=2242|std=C++98|before=it was unclear whether a {{tt|const}} object that is only<br>constant-initialized in part of its definitions violates ODR|after=ODR is not violated; the object is<br>constant-initialized in this case}}
 +
{{dr list item|wg=cwg|dr=2300|std=C++11|before=lambda expressions in different translation<br>units could never have the same closure type|after=the closure type can be the<br>same under one definition rule}}
 +
{{dr list item|wg=cwg|dr=2353|std=C++98|before=a static data member was not a potential result<br>of a member access expression accessing it|after=it is}}
 +
{{dr list item|wg=cwg|dr=2433|std=C++14|before=a variable template could not have multiple definitions in a program|after=it can}}
 +
{{dr list end}}
  
 
===References===
 
===References===
 +
{{ref std c++23}}
 +
{{ref std|section=6.3|title=One definition rule|id=basic.def.odr}}
 +
{{ref std end}}
 +
{{ref std c++20}}
 +
{{ref std|section=6.3|title=One definition rule|id=basic.def.odr}}
 +
{{ref std end}}
 +
{{ref std c++17}}
 +
{{ref std|section=6.2|title=One definition rule|id=basic.def.odr}}
 +
{{ref std end}}
 +
{{ref std c++14}}
 +
{{ref std|section=3.2|title=One definition rule|id=basic.def.odr}}
 +
{{ref std end}}
 
{{ref std c++11}}
 
{{ref std c++11}}
{{ref std | section=3.2 | title=One definition rule | id=basic.def.odr}}
+
{{ref std|section=3.2|title=One definition rule|id=basic.def.odr}}
 +
{{ref std end}}
 +
{{ref std c++03}}
 +
{{ref std|section=3.2|title=One definition rule|id=basic.def.odr}}
 +
{{ref std end}}
 +
{{ref std c++98}}
 +
{{ref std|section=3.2|title=One definition rule|id=basic.def.odr}}
 
{{ref std end}}
 
{{ref std end}}
  
{{langlinks|es|zh}}
+
{{langlinks|es|ja|ru|zh}}

Latest revision as of 22:22, 30 May 2024

 
 
C++ language
General topics
Flow control
Conditional execution statements
if
Iteration statements (loops)
for
range-for (C++11)
Jump statements
Functions
Function declaration
Lambda function expression
inline specifier
Dynamic exception specifications (until C++17*)
noexcept specifier (C++11)
Exceptions
Namespaces
Types
Specifiers
const/volatile
decltype (C++11)
auto (C++11)
constexpr (C++11)
consteval (C++20)
constinit (C++20)
Storage duration specifiers
Initialization
Expressions
Alternative representations
Literals
Boolean - Integer - Floating-point
Character - String - nullptr (C++11)
User-defined (C++11)
Utilities
Attributes (C++11)
Types
typedef declaration
Type alias declaration (C++11)
Casts
Memory allocation
Classes
Class-specific function properties
explicit (C++11)
static

Special member functions
Templates
Miscellaneous
 
 

Definitions are declarations that fully define the entity introduced by the declaration. Every declaration is a definition, except for the following:

  • A function declaration without a function body:
int f(int); // declares, but doesn't define f
extern const int a;     // declares, but doesn't define a
extern const int b = 1; // defines b
struct S
{
    int n;               // defines S::n
    static int i;        // declares, but doesn't define S::i
    inline static int x; // defines S::x
};                       // defines S
 
int S::i;                // defines S::i
  • (deprecated) Namespace scope declaration of a static data member that was defined within the class with the constexpr specifier:
struct S
{
    static constexpr int x = 42; // implicitly inline, defines S::x
};
 
constexpr int S::x; // declares S::x, not a redefinition
(since C++17)
  • Declaration of a class name (by forward declaration or by the use of the elaborated type specifier in another declaration):
struct S;             // declares, but doesn't define S
 
class Y f(class T p); // declares, but doesn't define Y and T (and also f and p)
enum Color : int; // declares, but doesn't define Color
(since C++11)
template<typename T> // declares, but doesn't define T
  • A parameter declaration in a function declaration that isn't a definition:
int f(int x); // declares, but doesn't define f and x
 
int f(int x)  // defines f and x
{
    return x + a;
}
typedef S S2; // declares, but doesn't define S2 (S may be incomplete)
using S2 = S; // declares, but doesn't define S2 (S may be incomplete)
(since C++11)
using N::d; // declares, but doesn't define d
(since C++17)
(since C++11)
extern template
f<int, char>; // declares, but doesn't define f<int, char>
(since C++11)
template<>
struct A<int>; // declares, but doesn't define A<int>

An asm declaration does not define any entities, but it is classified as a definition.

Where necessary, the compiler may implicitly define the default constructor, copy constructor, move constructor, copy assignment operator, move assignment operator, and the destructor.

If the definition of any object results in an object of incomplete type or abstract class type, the program is ill-formed.

Contents

[edit] One Definition Rule

Only one definition of any variable, function, class type, enumeration type, concept(since C++20) or template is allowed in any one translation unit (some of these may have multiple declarations, but only one definition is allowed).

One and only one definition of every non-inline function or variable that is odr-used (see below) is required to appear in the entire program (including any standard and user-defined libraries). The compiler is not required to diagnose this violation, but the behavior of the program that violates it is undefined.

For an inline function or inline variable(since C++17), a definition is required in every translation unit where it is odr-used.

For a class, a definition is required wherever the class is used in a way that requires it to be complete.

There can be more than one definition in a program of each of the following: class type, enumeration type, inline function, inline variable(since C++17), templated entity (template or member of template, but not full template specialization), as long as all of the following is true:

  • each definition appears in a different translation unit
(since C++20)
  • each definition consists of the same sequence of tokens (typically, appears in the same header file)
  • name lookup from within each definition finds the same entities (after overload-resolution), except that
  • constants with internal or no linkage may refer to different objects as long as they are not odr-used and have the same values in every definition
  • lambda-expressions that are not in a default argument or a default template argument(since C++20) are uniquely identified by the sequence of tokens used to define them
(since C++11)
  • overloaded operators, including conversion, allocation, and deallocation functions refer to the same function from each definition (unless referring to one defined within the definition)
  • corresponding entities have the same language linkage in each definition (e.g. the include file isn't inside an extern "C" block)
  • if a const object is constant-initialized in any of the definitions, it is constant-initialized in each definition
  • the rules above apply to every default argument used in each definition
  • if the definition is for a class with an implicitly-declared constructor, every translation unit where it is odr-used must call the same constructor for the base and members
  • if the definition is for a class with a defaulted three-way comparison, every translation unit where it is odr-used must call the same comparison operator for the base and members
(since C++20)
  • if the definition is for a template, then all these requirements apply to both names at the point of definition and dependent names at the point of instantiation

If all these requirements are satisfied, the program behaves as if there is only one definition in the entire program. Otherwise, the program is ill-formed, no diagnostic required.

Note: in C, there is no program-wide ODR for types, and even extern declarations of the same variable in different translation units may have different types as long as they are compatible. In C++, the source-code tokens used in declarations of the same type must be the same as described above: if one .cpp file defines struct S { int x; }; and the other .cpp file defines struct S { int y; };, the behavior of the program that links them together is undefined. This is usually resolved with unnamed namespaces.

[edit] ODR-use

Informally,

  • an object is odr-used if its value is read (unless it is a compile time constant) or written, its address is taken, or a reference is bound to it,
  • a reference is odr-used if it is used and its referent is not known at compile time,
  • a function is odr-used if a function call to it is made or its address is taken.

If an object, a reference or a function is odr-used, its definition must exist somewhere in the program; a violation of that is usually a link-time error.

struct S
{
    static const int x = 0; // static data member
    // a definition outside of class is required if it is odr-used
};
 
const int& f(const int& r);
 
int n = b ? (1, S::x) // S::x is not odr-used here
          : f(S::x);  // S::x is odr-used here: a definition is required

Formally,

1) a variable x in a potentially-evaluated expression ex is odr-used unless both of the following are true:
  • applying lvalue-to-rvalue conversion to x yields a constant expression that doesn't invoke non-trivial functions
  • either x is not an object (that is, x is a reference) or, if x is an object, it is one of the potential results of a larger expression e, where that larger expression is either a discarded-value expression or has the lvalue-to-rvalue conversion applied to it
struct S { static const int x = 1; }; // applying lvalue-to-rvalue conversion
                                      // to S::x yields a constant expression
 
int f()
{
    S::x;        // discarded-value expression does not odr-use S::x
 
    return S::x; // expression where lvalue-to-rvalue conversion
                 // applies does not odr-use S::x
}
2) *this is odr-used if this appears as a potentially-evaluated expression (including the implicit this in a non-static member function call expression)
3) A structured binding is odr-used if it appears as a potentially-evaluated expression.
(since C++17)

A set of potential results of an expression E is a (possibly empty) set of id-expressions that appear within E, combined as follows:

  • If E is an id-expression, the expression E is its only potential result.
  • If E is a subscript expression (E1[E2]) where one of the operands is an array, the potential results of that operand is included in the set.
  • If E is a class member access expression of the form E1.E2 or E1.template E2 naming a non-static data member, the potential results of E1 is included in the set.
  • If E is a class member access expression naming a static data member, the id-expression designating the data member is included in the set.
  • If E is a pointer-to-member access expression of the form E1.*E2 or E1.*template E2 whose second operand is a constant expression, the potential results of E1 are included in the set.
  • If E is an expression in parentheses ((E1)), the potential results of E1 are included in the set.
  • If E is a glvalue conditional expression (E1 ? E2 : E3, where E2 and E3 are glvalues), the union of the potential results of E2 and E3 are both included in the set.
  • If E is a comma expression (E1, E2), the potential results of E2 are in the set of potential results.
  • Otherwise, the set is empty.
struct S
{
    static const int a = 1;
    static const int b = 2;
};
 
int f(bool x)
{
    return x ? S::a : S::b;
    // x is a part of the subexpression "x" (to the left of ?),
    // which applies lvalue-to-rvalue conversion, but applying that conversion to x
    // does not yield a constant expression, so x is odr-used
    // S::a and S::b are lvalues, and carry over as "potential results"
    // to the result of the glvalue conditional
    // That result is then subject to lvalue-to-rvalue conversion requested
    // to copy-initialize the return value, therefore S::a and S::b are not odr-used
}
4) A function is odr-used in following cases:
  • A function is odr-used if it is named by (see below) a potentially-evaluated expression or conversion.
  • A virtual member function is odr-used if it is not a pure virtual member function (addresses of virtual member functions are required to construct the vtable).
  • A non-placement allocation or deallocation function for a class is odr-used by the definition of a constructor of that class.
  • A non-placement deallocation function for a class is odr-used by the definition of the destructor of that class, or by being selected by the lookup at the point of definition of a virtual destructor.
  • An assignment operator in a class T that is a member or base of another class U is odr-used by an implicitly-defined copy-assignment or move-assignment functions of U.
  • A constructor (including default constructors) for a class is odr-used by the initialization that selects it.
  • A destructor for a class is odr-used if it is potentially invoked.

[edit] Naming a function

A function is named by an expression or conversion in following cases:

  • A function whose name appears as an expression or conversion (including named function, overloaded operator, user-defined conversion, user-defined placement forms of operator new, non-default initialization) is named by that expression if it is selected by overload resolution, except when it is an unqualified pure virtual member function or a pointer-to-member to a pure virtual function.
  • An allocation or deallocation function for a class is named by a new expression appearing in an expression.
  • A deallocation function for a class is named by a delete expression appearing in an expression.
  • A constructor selected to copy or move an object is considered to be named by the expression or conversion even if copy elision takes place. Using a prvalue in some contexts does not copy or move an object, see mandatory elision.(since C++17)

A potentially evaluated expression or conversion odr-uses a function if it names it.

A potentially constant evaluated expression or conversion that names a constexpr function makes it needed for constant evaluation, which triggers definition of a defaulted function or instantiation of a function template specialization, even if the expression is unevaluated.

(since C++11)

[edit] Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

DR Applied to Behavior as published Correct behavior
CWG 261 C++98 a deallocation function for a polymorphic class
might be odr-used even if there were no relevant
new or delete expressions in the program
supplemented the
odr-use cases to cover
constructors and destructors
CWG 678 C++98 an entity could have definitions
with different language linkages
the behavior is
undefined in this case
CWG 1472 C++98 reference variables which satisfy the requirements for
appearing in a constant expression were odr-used even
if the lvalue-to-rvalue conversion is immediately applied
they are not odr-used
in this case
CWG 1614 C++98 taking address of a pure virtual function odr-used it the function is not odr-used
CWG 1741 C++98 constant objects that are immediately lvalue-to-rvalue
converted in potentially-evaluated expressions were odr-used
they are not odr-used
CWG 1926 C++98 array subscript expressions didn't propagate potential results they propagate
CWG 2242 C++98 it was unclear whether a const object that is only
constant-initialized in part of its definitions violates ODR
ODR is not violated; the object is
constant-initialized in this case
CWG 2300 C++11 lambda expressions in different translation
units could never have the same closure type
the closure type can be the
same under one definition rule
CWG 2353 C++98 a static data member was not a potential result
of a member access expression accessing it
it is
CWG 2433 C++14 a variable template could not have multiple definitions in a program it can

[edit] References

  • C++23 standard (ISO/IEC 14882:2024):
  • 6.3 One definition rule [basic.def.odr]
  • C++20 standard (ISO/IEC 14882:2020):
  • 6.3 One definition rule [basic.def.odr]
  • C++17 standard (ISO/IEC 14882:2017):
  • 6.2 One definition rule [basic.def.odr]
  • C++14 standard (ISO/IEC 14882:2014):
  • 3.2 One definition rule [basic.def.odr]
  • C++11 standard (ISO/IEC 14882:2011):
  • 3.2 One definition rule [basic.def.odr]
  • C++03 standard (ISO/IEC 14882:2003):
  • 3.2 One definition rule [basic.def.odr]
  • C++98 standard (ISO/IEC 14882:1998):
  • 3.2 One definition rule [basic.def.odr]