No translation unit shall contain more than one definition of any variable, function, class type, enumeration type, or template.
An expression is potentially evaluated unless it is an unevaluated operand (Clause [expr]) or a subexpression thereof. A variable whose name appears as a potentially-evaluated expression is odr-used unless it is an object that satisfies the requirements for appearing in a constant expression ([expr.const]) and the lvalue-to-rvalue conversion ([conv.lval]) is immediately applied. this is odr-used if it appears as a potentially-evaluated expression (including as the result of the implicit transformation in the body of a non-static member function ([class.mfct.non-static])). A virtual member function is odr-used if it is not pure. A non-overloaded function whose name appears as a potentially-evaluated expression or a member of a set of candidate functions, if selected by overload resolution when referred to from a potentially-evaluated expression, is odr-used, unless it is a pure virtual function and its name is not explicitly qualified. [ Note: This covers calls to named functions ([expr.call]), operator overloading (Clause [over]), user-defined conversions ([class.conv.fct]), allocation function for placement new ([expr.new]), as well as non-default initialization ([dcl.init]). A copy constructor or move constructor is odr-used even if the call is actually elided by the implementation. — end note ] An allocation or deallocation function for a class is odr-used by a new expression appearing in a potentially-evaluated expression as specified in [expr.new] and [class.free]. A deallocation function for a class is odr-used by a delete expression appearing in a potentially-evaluated expression as specified in [expr.delete] and [class.free]. 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 ([class.dtor]).26 A copy-assignment function for a class is odr-used by an implicitly-defined copy-assignment function for another class as specified in [class.copy]. A move-assignment function for a class is odr-used by an implicitly-defined move-assignment function for another class as specified in [class.copy]. A default constructor for a class is odr-used by default initialization or value initialization as specified in [dcl.init]. A constructor for a class is odr-used as specified in [dcl.init]. A destructor for a class is odr-used as specified in [class.dtor].
Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required. The definition can appear explicitly in the program, it can be found in the standard or a user-defined library, or (when appropriate) it is implicitly defined (see [class.ctor], [class.dtor] and [class.copy]). An inline function shall be defined in every translation unit in which it is odr-used.
Exactly one definition of a class is required in a translation unit if the class is used in a way that requires the class type to be complete. [ Example: the following complete translation unit is well-formed, even though it never defines X:
struct X; // declare X as a struct type struct X* x1; // use X in pointer formation X* x2; // use X in pointer formation
— end example ] [ Note: The rules for declarations and expressions describe in which contexts complete class types are required. A class type T must be complete if:
an object of type T is defined ([basic.def]), or
a non-static class data member of type T is declared ([class.mem]), or
T is used as the object type or array element type in a new-expression ([expr.new]), or
an lvalue-to-rvalue conversion is applied to a glvalue referring to an object of type T ([conv.lval]), or
an expression is converted (either implicitly or explicitly) to type T (Clause [conv], [expr.type.conv], [expr.dynamic.cast], [expr.static.cast], [expr.cast]), or
an expression that is not a null pointer constant, and has type other than void*, is converted to the type pointer to T or reference to T using an implicit conversion (Clause [conv]), a dynamic_cast ([expr.dynamic.cast]) or a static_cast ([expr.static.cast]), or
a class member access operator is applied to an expression of type T ([expr.ref]), or
the typeid operator ([expr.typeid]) or the sizeof operator ([expr.sizeof]) is applied to an operand of type T, or
a function with a return type or argument type of type T is defined ([basic.def]) or called ([expr.call]), or
a class with a base class of type T is defined (Clause [class.derived]), or
an lvalue of type T is assigned to ([expr.ass]), or
the type T is the subject of an alignof expression ([expr.alignof]), or
an exception-declaration has type T, reference to T, or pointer to T ([except.handle]).
— end note ]
There can be more than one definition of a class type (Clause [class]), enumeration type ([dcl.enum]), inline function with external linkage ([dcl.fct.spec]), class template (Clause [temp]), non-static function template ([temp.fct]), static data member of a class template ([temp.static]), member function of a class template ([temp.mem.func]), or template specialization for which some template parameters are not specified ([temp.spec], [temp.class.spec]) in a program provided that each definition appears in a different translation unit, and provided the definitions satisfy the following requirements. Given such an entity named D defined in more than one translation unit, then
each definition of D shall consist of the same sequence of tokens; and
in each definition of D, corresponding names, looked up according to [basic.lookup], shall refer to an entity defined within the definition of D, or shall refer to the same entity, after overload resolution ([over.match]) and after matching of partial template specialization ([temp.over]), except that a name can refer to a const object with internal or no linkage if the object has the same literal type in all definitions of D, and the object is initialized with a constant expression ([expr.const]), and the value (but not the address) of the object is used, and the object has the same value in all definitions of D; and
in each definition of D, corresponding entities shall have the same language linkage; and
in each definition of D, the overloaded operators referred to, the implicit calls to conversion functions, constructors, operator new functions and operator delete functions, shall refer to the same function, or to a function defined within the definition of D; and
in each definition of D, a default argument used by an (implicit or explicit) function call is treated as if its token sequence were present in the definition of D; that is, the default argument is subject to the three requirements described above (and, if the default argument has sub-expressions with default arguments, this requirement applies recursively).27
if D is a class with an implicitly-declared constructor ([class.ctor]), it is as if the constructor was implicitly defined in every translation unit where it is odr-used, and the implicit definition in every translation unit shall call the same constructor for a base class or a class member of D. [ Example:
//translation unit 1: struct X { X(int); X(int, int); }; X::X(int = 0) { } class D: public X { }; D d2; // X(int) called by D() //translation unit 2: struct X { X(int); X(int, int); }; X::X(int = 0, int = 0) { } class D: public X { }; // X(int, int) called by D(); // D()'s implicit definition // violates the ODR
— end example ]
If D is a template and is defined in more than one translation unit, then the preceding requirements shall apply both to names from the template's enclosing scope used in the template definition ([temp.nondep]), and also to dependent names at the point of instantiation ([temp.dep]). If the definitions of D satisfy all these requirements, then the program shall behave as if there were a single definition of D. If the definitions of D do not satisfy these requirements, then the behavior is undefined.
An implementation is not required to call allocation and deallocation functions from constructors or destructors; however, this is a permissible implementation technique.
[dcl.fct.default] describes how default argument names are looked up.