cpp/language/definition

Definitions are 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:


 * Any declaration with an  or with a  specifier (such as ) without an initializer:


 * Declaration of a  inside a class definition:


 * Declaration of a class name (by or by the use of the elaborated type specifier in another declaration):


 * Declaration of a :


 * A parameter declaration in a function declaration that isn't a definition:


 * A declaration:


 * A :


 * An (does not define any entities)
 * A (does not define any entities)


 * An whose declaration is not a definition:

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

Where necessary, the compiler may implicitly define the, , , , , and the.

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

One Definition Rule
Only one definition of any variable, function, class type, enumeration type, 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- 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, 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.

There can be more than one definition in a program of each of the following: class type, enumeration type, inline function, (template or member of template, but not full ), as long as all of the following is true:
 * each definition appears in a different translation unit


 * 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


 * 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 object is  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 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 and the other .cpp file defines, the behavior of the program that links them together is undefined. This is usually resolved with.

ODR-use
Informally, 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.

Formally, @1@ a variable in a   is odr-used unless both of the following are true:
 * applying lvalue-to-rvalue conversion to yields a constant expression that doesn't invoke non-trivial functions
 * either is not an object (that is,  is a reference) or, if  is an object, it is one of the potential results of a larger expression, where that larger expression is either a  or has the lvalue-to-rvalue conversion applied to it

@2@ is odr-used if  appears as a potentially-evaluated expression (including the implicit  in a non-static member function call expression)

A set of potential results of an expression is a (possibly empty) set of id-expressions that appear within, combined as follows:
 * If is an, the expression  is its only potential result.
 * If is a subscript expression  where one of the operands is an array, the potential results of that operand is included in the set.
 * If is a class member access expression of the form  or  naming a non-static data member, the potential results of  is included in the set.
 * If is a class member access expression naming a static data member, the id-expression designating the data member is included in the set.
 * If is a pointer-to-member access expression of the form  or  whose second operand is a constant expression, the potential results of  are included in the set.
 * If is an expression in parentheses, the potential results of  are included in the set.
 * If is a glvalue conditional expression (, where  and  are glvalues), the union of the potential results of  and  are both included in the set.
 * If is a comma expression, the potential results of  are in the set of potential results.
 * Otherwise, the set is empty.

@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 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 that is a member or base of another class  is odr-used by an implicitly-defined copy-assignment or move-assignment functions of.
 * A constructor (including default constructors) for a class is odr-used by the that selects it.
 * A destructor for a class is odr-used if it is potentially invoked.

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 placement forms of , 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 appearing in an expression.
 * A deallocation function for a class is named by a 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 takes place.

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