A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://en.cppreference.com/w/cpp/language/../language/definition.html below:

Definitions and ODR (One Definition Rule)

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

int f(int); // declares, but does not define f
extern const int a;     // declares, but does not define a
extern const int b = 1; // defines b
struct S
{
    int n;               // defines S::n
    static int i;        // declares, but does not define S::i
    inline static int x; // defines S::x
};                       // defines S
 
int S::i;                // defines S::i
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)
struct S;             // declares, but does not define S
 
class Y f(class T p); // declares, but does not define Y and T (and also f and p)
enum Color : int; // declares, but does not define Color
(since C++11)
template<typename T> // declares, but does not define T
int f(int x); // declares, but does not define f and x
 
int f(int x)  // defines f and x
{
    return x + a;
}
typedef S S2; // declares, but does not define S2 (S may be incomplete)
using S2 = S; // declares, but does not define S2 (S may be incomplete)
(since C++11)
using N::d; // declares, but does not define d
template<>
struct A<int>; // declares, but does not 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.

[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 following conditions are satisfied:

(since C++11) (since C++20)

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] Naming an entity

A variable is named by an expression if the expression is an identifier expression that denotes it.

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

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] Potential results

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

[edit] ODR-use (informal definition)

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 entity 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
[edit] ODR-use (formal definition)

A variable x that is named by a potentially-evaluated expression expr that appears at a point P is odr-used by expr, unless any of the following conditions is satisfied:

  • E has non-volatile-qualified non-class type, and the lvalue-to-rvalue conversion is 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
}

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

A structured binding is odr-used if it appears as a potentially-evaluated expression.

(since C++17)

A function is odr-used in following cases:

[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 did not 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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4