Are all constexpr variable implicitly inline?
No. Only constexpr functions and constexpr static data members are implicitly inline ([dcl.constexpr]/1).
Also, how does that affect the linkage of my variable bar?
A constexpr variable is const
([dcl.constexpr]/9). A non-inline const
variable that is not explicitly declared extern
has internal linkage ([basic.link]/3).
Well... Since you actually managed to get myself confused with your question, I thought I'd look further into it. First, we have to categorize the relevant properties of a variable: lifetime, visibility, linkage
These are influenced by the keywords: static
, inline
, constexpr
, const
, extern
which you use in your question.
At namespace scope in variable definition:
- static
: specifies internal linkage
- inline
: allows for multiple identical definitions of the same variable in different translation units and ensures they will refer to the same object (e.g have the same adresses)
- constexpr
: implies const
- const
: defaults to external linkage
- extern
: specifies external linkage
Thus,
- global_non_expl_inline
: defaults to external linkage. No problem, unless another translation unit defines another such variable with external linkage.
- global_non_expl_inline_static
: internal linkage. Fine, as long as you do not define other such variables anywhere.
- global_expl_inline
: External linkage and inline
. No problems, unless another translation unit declares another such variable without inline
.
- global_expl_inline_explicit_static
: Fine, a static inline
variable is meaningful, if you do not want it to be available at link time, but do want the same variable in all your translation units - e.g useful for all sorts of constants.
- global_expl_inline_explicit_extern
: External linkage and inline
. No problems, unless another translation unit declares another such variable without inline
.
- global_expl_inline_explicit_extern_but_unnamed_ns
: internal linkage according to cppreference.
At class scope:
- in_class_static
: external linkage. Fine, according to cppreference, but needs a declaration at namespace scope if it is odr-used.
- in_class_but_out_of_source_def
: external linkage. Also fine. This is actually the standard way.
In conclusion, there is (much) less undefined behaviour than you seem to think - which is good. There are however a few things, that are valid but do not really make sense like extern
in unnamed namespaces.
Regarding your comment about this question: I cannot reproduce the issue and neither could other people in the comment section of that question. There are also other plausibility issues with the question you can find in its comment section. Bear in mind, that some questions on stackoverflow are asked by people who do not exactly know which steps they take when running into problems. I would not bother too much about that particular question ;)
Best Answer
Yes,
constexpr
on an object declaration means that the object isconst
. See [dcl.constexpr]/9. And yes, that means thatkSomeString
in your example has internal linkage.The species of ODR violation we are talking about here is not the definition of
kSomeString
itself, but other definitions that attempt to use it. And there's a problem precisely because of the internal linkage. Consider:This is an ODR violation if included in multiple translation units, essentially because the definition of
g
in each translation unit references a different object.