Is a Constexpr Array Necessarily Odr-Used When Subscripted

Does a range based for loop over an array ODR-use the array?

Is the definition of foo::xs necessary?

Yes, because as NathanOliver points out in the comments, a reference is implicitly bound to foo::xs by the range-based for loop. When you bind a reference to an object, the object is odr-used. The same would occur if an std::array were used rather than a raw array.

What if we avoid the range based for?

Well, if you use a raw array and get its size using a technique that doesn't require binding a reference to it, then you can avoid providing a definition:

for (int i = 0; i < sizeof(foo::xs)/sizeof(foo::xs[0]); i++) {
    sum += foo::xs[i];
}

In this case, the references inside sizeof are not odr-uses because they are unevaluated, and foo::xs is an element of the set of potential results of foo::xs[i]; this latter expression is of non-class type and immediately undergoes an lvalue-to-rvalue conversion, so it does not odr-use foo::xs.

Strange behavior with constexpr static member variable

The standard does not require any diagnostics for a failure to provide a definition where one is required.

3.2 One definition rule [basic.def.odr]

4 Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required. [...]

This means implementations are allowed to optimise away accesses to such variables, and that's what's happening in your first case with GCC.

Both GCC and clang have decided that they prefer a consistent user experience, where error messages about missing definitions do not depend on the optimisation level. Usually, that means that any missing definition causes an error message. However, in this case, GCC is doing some minimal optimisation even at -O0, avoiding the error.

But the program is an error either way, because even A::dict[0] is an ODR-use:

3.2 One definition rule [basic.def.odr]

3 A variable x whose name appears as a potentially-evaluated expression ex is odr-used by ex unless applying the lvalue-to-rvalue conversion (4.1) to x yields a constant expression (5.19) that does not invoke any non-trivial functions and, if x is an object, ex is an element of the set of potential results of an expression e, where either the lvalue-to-rvalue conversion (4.1) is applied to e, or e is a discarded-value expression (Clause 5). [...]

The use of A::dict doesn't involve lvalue-to-rvalue conversion, it involves the array-to-pointer conversion, so the exception doesn't apply.

constexpr global constants in a header file and odr

Note: as of C++17, you can declare your variables as inline.

---

TL;DR: If you want to be on the (very) safe side, go with constexpr functions. It isn't inherently necessary though, and certainly won't be if you're performing trivial operations on these objects and are solely interested in their value, or simply don't use them in the dangerous scenarios listed below.

The fundamental issue is that const variables at namespace scope such as yours (generally) have internal linkage ([basic.link]/(3.2)). This implies that each translation unit compiling the corresponding header will observe a different entity (i.e. symbol).

Now imagine we have a template or inline function in a header using those objects. The ODR is very precise about this scenario - [basic.def.odr]/6:

"initialized with a constant expression" is certainly met, since we're talking constexpr. So is "the object has the same value in all definitions of D" if you don't monkey about.

"the object isn't odr-used" is probably the only questionable condition. Basically, it requires that you don't necessitate the variables runtime existence as a symbol, which in turn implies that

• You don't bind it to a reference (=> you don't forward it!)

• You don't (neither explicitly nor implicitly) take its address.

The only exception to the second rule are arrays, which can be taken the address of implicitly inside a subscript operation as long as the two above rules aren't violated for the yielded glvalue.

More precisely, odr-use is governed by [basic.def.odr]/3:

A variable x whose name appears as a potentially-evaluated expression ex is odr-used by ex unless applying
the lvalue-to-rvalue conversion (4.1) to x yields a constant expression (5.20) that does not invoke any non-trivial functions and, if x is an object, ex is an element of the set of potential results of an expression e, where either the lvalue-to-rvalue conversion (4.1) is applied to e, or e is a discarded-value expression (Clause
5).

Applying l-t-r to any constexpr variable will behave as required by the first part. The second part requires that the variable be used as a value rather than an actual object; that is, it's eventually either discarded or directly evaluated, giving the above rules of thumb.

If you avoid odr-use of the variable inside inline functions, templates or the like, you're fine. But if you use the return value of a corresponding constexpr function, you won't have to worry, since prvalues are already behaving more like values/literals (not objects) and constexpr functions are inline and definitely won't violate the ODR (if you don't use constexpr variables inside there!).

What does it mean to ODR-use something?

It's just an arbitrary definition, used by the standard to
specify when you must provide a definition for an entity (as
opposed to just a declaration). The standard doesn't say just
"used", because this can be interpreted diversely depending on
context. And some ODR-use doesn't really correspond to what one
would normally associate with "use"; for example, a virtual
function is always ODR-used unless it is pure, even if it isn't
actually called anywhere in the program.

The full definition is in §3.2, second paragraph, although this
contains references to other sections to complete the
definition.

With regards to templates, ODR-used is only part of question;
the other part is instantiation. In particular, §14.7 covers
when a template is instantiated. But the two are related: while
the text in §14.7.1 (implicit instantiation) is fairly long, the
basic principle is that a template will only be instantiated if
it is used, and in this context, used means ODR-used. Thus,
a member function of a class template will only be instantiated
if it is called, or if it is virtual and the class itself is
instantiated. The standard itself counts on this in many
places: the std::list<>::sort uses < on the individual
elements, but you can instantiate a list over an element type
which doesn't support <, as long as you don't call sort on
it.

Access static constexpr std::array without out-of-class definition

As per @dyp suggestion, I looked into the definition of static data members.

My problem requires me to define the static member variables of my Points class.

Following the examples in these questions:

Is a constexpr array necessarily odr-used when subscripted?

and

Defining static members in C++

I need to add:

// in some .cpp
constexpr std::array< double, 1 > Points::a1;

Understanding the example on lvalue-to-rvalue conversion

This is because y.n is not odr-used and therefore does not require an access to y.n the rules for odr-use are covered in 3.2 and says:

A variable x whose name appears as a potentially-evaluated expression ex is odr-used unless applying the
lvalue-to-rvalue conversion (4.1) to x yields a constant expression (5.19) that does not invoke any non-trivial
functions and, if x is an object, ex is an element of the set of potential results of an expression e, where
either the lvalue-to-rvalue conversion (4.1) is applied to e, or e is a discarded-value expression

Note, Ben Voigt made some helpful comments that clarified this one a bit. So the working assumption here is that x would be:

y

and e would be(the different expression that e is defined for is covered in paragraph 2 of section 3.2):

(b ? y : x).n

y yields a constant expression and the lvalue-to-rvalue conversion is applied to the expression e.

Since f yields a lambda which captures f's local variables by reference x is no longer valid once the call to f is done since x is an automatic variable inside f. Since y is a constant expression it acts as if y.n was not accessed and therefore we don't have the same lifetime issue.

Your example is included in N3939 section 4.1 [conv.lval] and right before that example it says:

When an lvalue-to-rvalue conversion is applied to an expression e, and either

and includes the following bullet which the examle belongs to:

the evaluation of e results in the evaluation of a member ex of the set of potential results of e, and
ex names a variable x that is not odr-used by ex (3.2),

then:

the value contained in the referenced object is not accessed

This was applied to the C++14 draft standard due to defect report 1773 .

---

Related Topics