Definitions and ODR

 

C++

Language

Standard library headers

Concepts

Utilities library

Strings library

Containers library

Algorithms library

Iterators library

Numerics library

Input/output library

Localizations library

Regular expressions library (C++11)

Atomic operations library (C++11)

Thread support library (C++11)

Technical Specifications

 

C++ language

 

Basic Concepts

language keywords

phases of translation

comments

the main() function

names and identifiers

types

fundamental types

objects

scope

object lifetime

storage duration and linkage

definitions and ODR

name lookup

qualified name lookup

unqualified name lookup

memory model

 

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

• Any declaration with an extern storage class specifier or with a language linkage specifier (such as extern "C") without an initializer

extern const int a; // declares, but doesn't define a
extern const int b = 1; // defines b

• A function declaration without a function body

int f(int); // declares, but doesn't define f

• 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;
}

• Declaration of a static data member inside a class definition

struct S {    // defines S
    int n;        // defines S::n
    static int i; // declares, but doesn't define S::i
};
int S::i; // defines S::i

• 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)

• Declaration of a template parameter

template<typename T> // declares, but doesn't define T

• An explicit specialization whose declaration is not a definition.

template<> struct A<int>; // declares, but doesn't define A<int>

• A typedef declaration

typedef S S2; // declares, but doesn't define S2 (S may be incomplete)

An alias-declaration using S2 = S; // declares, but doesn't define S2 (S may be incomplete) An opaque declaration of an enumeration enum Color : int; // declares, but doesn't define Color

(since C++11)

• A using-declaration

using N::d; // declares, but doesn't define d

• A using-directive (does not define any entities)

A static_assert declaration (does not define any entities) An attribute declaration (does not define any entities) An explicit instantiation declaration (an "extern template") extern template f<int, char>; // declares, but doesn't define f<int, char>

(since C++11)

• An empty declaration (does not define any entities)

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, 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-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, 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 complete.

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, class template, non-static function template, static data member of a class template, member function of a class template, partial template specialization, 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)
• 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)
• the language linkage is the same (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 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 behavior is undefined.

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.

ODR-use

Informally, an object is odr-used if its address is taken, or a reference is bound to it, and a function is odr-used if a function call to it is made or its address is taken. If an object or a function is odr-used, its definition must exist somewhere in the program; a violation of that is 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

struct S { static const int x = 1; };
int f() { return S::x; } // does not odr-use S::x

• 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 an lvalue-to-rvalue conversion

struct S { static const int x = 1; };
void f() { &S::x; } // discarded-value expression does not odr-use S::x

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

In the definitions above, potentially-evaluated means the expression is not an unevaluated operand (or its subexpression), such as the operand of sizeof and 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 an array subscript expression (e1[e2]) and the operand (e1) is array, that array is included in the set

(since C++17)

• If e is a class member access expression (e1.e2 or e1->e2), the potential results of the object expression e1 is included in the set.
• If e is a pointer-to-member access expression (e1.*e2 or e1->*e2) whose second operand is a constant expression, the potential results of the object expression 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, therefore x is not 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) Functions are ODR-used if

• A function whose name appears as a potentially-evaluated expression (including named function, overloaded 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 or a pointer-to-member to a pure virtual function (since C++17).
• 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 allocation or deallocation function for a class is odr-used by a new expression appearing in a potentially-evaluated expression
• A deallocation function for a class is odr-used by a 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 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

In all cases, a constructor selected to copy or move an object is odr-used even if copy elision takes place.