C++ Linker Error With Class static constexpr

Question

I am compiling the following simple program with g++-4.6.1 --std=c++0x:

#include <algorithm>

struct S
{
    static constexpr int X = 10;
};

int main()
{
    return std::min(S::X, 0);
};

I get the following linker error:

/tmp/ccBj7UBt.o: In function `main':
scratch.cpp:(.text+0x17): undefined reference to `S::X'
collect2: ld returned 1 exit status

I realize that inline-defined static members do not have symbols defined, but I was under the (probably flawed) impression that using constexpr told the compiler to always treat the symbol as an expression; so, the compiler would know that it is not legal to pass a reference to the symbol S::X (for the same reason you can't take a reference to the literal 10).

However if S is declared as namespace, i.e. "namespace S" instead of "struct S", everything links fine.

Is this a g++ bug or do I still have to use a trick to workaround this annoyance?

Answer 1

This has been fixed in C++17.

https://en.cppreference.com/w/cpp/language/static:

If a static data member is declared constexpr, it is implicitly inline and does not need to be redeclared at namespace scope. This redeclaration without an initializer (formerly required as shown above) is still permitted, but is deprecated.

Answer 2

I don't think this is a bug. If you change the constexpr to const, it still fails, with the exact same error.

You've declared S::X, but not defined it anywhere, so there's no storage for it. If you do anything with it that needs to know the address of it then you'll need to define it somewhere also.

Examples:

int main() {
      int i = S::X; // fine
      foo<S::X>(); // fine
      const int *p = &S::X; // needs definition
      return std::min(S::X, 0); // needs it also
}

The reason for this is that constexpr can be evaluated at compile time, but it's not required to be evaluated as such, and can equally happen at runtime. It doesn't instruct "the compiler to always treat the symbol as an expression", it hints that it would be sensible and permissible to do so if the compiler felt like it.

Answer 3

In the C++ standard (latest working draft), it says:

A name having namespace scope (3.3.6) has internal linkage if it is the name of [...] a variable that is explicitly declared const or constexpr and neither explicitly declared extern nor previously declared to have external linkage [...].

"Linkage" is defined like this:

A name is said to have linkage when it might denote the same object, reference, function, type, template, namespace or value as a name introduced by a declaration in another scope:

— When a name has external linkage, the entity it denotes can be referred to by names from scopes of other translation units or from other scopes of the same translation unit.

— When a name has internal linkage, the entity it denotes can be referred to by names from other scopes in the same translation unit.

— When a name has no linkage, the entity it denotes cannot be referred to by names from other scopes.

Thus, in case of namespace S, it will have external linkage, in case of struct S, it will have internal linkage.

Symbols with external linkage need to have the symbol defined explicitly in some translation unit.

Answer 4

The reason for the error has been already explained, so I'd just add a workaround.

return std::min(int(S::X), 0);

This creates a temporary, so std::min could take a reference to it.

Answer 5

You also need to provide a definition for the constexpr member outside the struct (or class), but this time without its value. See here: https://en.cppreference.com/w/cpp/language/static

#include <algorithm>

struct S
{
    static constexpr int X = 10;
};

constexpr int S::X;

int main()
{
    return std::min(S::X, 0);
};

Answer 6

Your understanding of constexpr is wrong. An lvalue declared constexpr is still an lvalue, and a function declared constexpr is still a function. And when a function has a reference parameter, and it is passed an lvalue, the language requires that the reference refer to that lvalue, and nothing else. (When applied to a variable of type int, there is really very little difference between constexpr and plain const.)