Referencia indefinida a static constexpr char []

Quiero tener una static const charmatriz en mi clase. GCC se quejó y me dijo que debería usar constexpr, aunque ahora me dice que es una referencia indefinida. Si hago que la matriz no sea miembro, entonces se compila. Que esta pasando?

// .hpp
struct foo {
  void bar();
  static constexpr char baz[] = "quz";
};

// .cpp
void foo::bar() {
  std::string str(baz); // undefined reference to baz
}

Agregar a su archivo cpp:

constexpr char foo::baz[];

Motivo: debe proporcionar la definición del miembro estático y la declaración. La declaración y el inicializador van dentro de la definición de clase, pero la definición de miembro debe estar separada.

C ++ 17 introduce variables en línea

C ++ 17 corrige este problema para las constexpr staticvariables miembro que requieren una definición fuera de línea si se usaba odr. Consulte la segunda mitad de esta respuesta para obtener detalles anteriores a C ++ 17.

La propuesta P0386 Variables en línea introduce la capacidad de aplicar el inlineespecificador a las variables. En particular para este caso constexprimplica inlinepara las variables miembro estáticas. La propuesta dice:

El especificador en línea se puede aplicar tanto a las variables como a las funciones. Una variable declarada en línea tiene la misma semántica que una función declarada en línea: se puede definir, de manera idéntica, en múltiples unidades de traducción, se debe definir en cada unidad de traducción en la que se usa odr, y el comportamiento del programa es como si Hay exactamente una variable.

y modificado [basic.def] p2:

Una declaración es una definición a menos que
...

• declara un miembro de datos estático fuera de una definición de clase y la variable se definió dentro de la clase con el especificador constexpr (este uso está en desuso; consulte [depr.static_constexpr]),

...

y agregue [depr.static_constexpr] :

Para compatibilidad con estándares internacionales anteriores de C ++, un miembro de datos estáticos constexpr puede ser redeclarado de forma redundante fuera de la clase sin inicializador. Este uso está en desuso. [Ejemplo:

struct A {
  static constexpr int n = 5;  // definition (declaration in C++ 2014)
};

constexpr int A::n;  // redundant declaration (definition in C++ 2014)

 - ejemplo final]

C ++ 14 y anterior

En C ++ 03, solo se nos permitía proporcionar inicializadores en clase para integrales const o tipos de enumeración const , en C ++ 11 el uso constexprse extendió a los tipos literales .

En C ++ 11, no necesitamos proporcionar una definición de alcance de espacio de nombres para un constexprmiembro estático si no se usa odr , podemos ver esto en el borrador de la sección estándar de C ++ 11 9.4.2 [class.static.data] que dice ( énfasis mío en el futuro ):

[...] Un miembro de datos estáticos de tipo literal se puede declarar en la definición de clase con el especificador constexpr; en caso afirmativo, su declaración especificará un inicializador de llave o igual en el que cada cláusula de inicializador que sea una expresión de asignación es una expresión constante. [Nota: en ambos casos, el miembro puede aparecer en expresiones constantes. —Nota final] El miembro todavía se definirá en un ámbito de espacio de nombres si se utiliza odr-(3.2) en el programa y la definición del ámbito de nombres no contendrá un inicializador.

Entonces la pregunta es, ¿se baz usa odr aquí:

std::string str(baz); 

y la respuesta es sí , por lo que también necesitamos una definición del alcance del espacio de nombres.

Entonces, ¿cómo determinamos si una variable se usa odr ? La redacción original de C ++ 11 en la sección 3.2 [basic.def.odr] dice:

Una expresión se evalúa potencialmente a menos que sea un operando no evaluado (Cláusula 5) o una subexpresión del mismo. Una variable cuyo nombre aparece como una expresión potencialmente evaluada se usa odr a menos que sea un objeto que satisfaga los requisitos para aparecer en una expresión constante (5.19) y se aplique inmediatamente la conversión lvalue-to-rvalue (4.1) .

Por bazlo tanto , produce una expresión constante, pero la conversión lvalue-to-rvalue no se aplica inmediatamente ya que no es aplicable debido a que bazes una matriz. Esto está cubierto en la sección 4.1 [conv.lval] que dice:

Un valor de gl (3.10) de un tipo T sin función y sin matriz se puede convertir en un valor de valor.53 [...]

Lo que se aplica en la conversión de matriz a puntero .

Esta redacción de [basic.def.odr] se modificó debido al Informe de defectos 712 ya que algunos casos no estaban cubiertos por esta redacción, pero estos cambios no cambian los resultados para este caso.

Esto es realmente una falla en C ++ 11: como han explicado otros, en C ++ 11 una variable miembro estática constexpr, a diferencia de cualquier otro tipo de variable global constexpr, tiene un enlace externo, por lo que debe definirse explícitamente en alguna parte.

También vale la pena señalar que, en la práctica, a menudo puede salirse con la suya con variables miembro estáticas constexpr sin definiciones al compilar con la optimización, ya que pueden terminar en línea en todos los usos, pero si compila sin optimización, a menudo su programa no podrá vincularse. Esto lo convierte en una trampa oculta muy común: su programa se compila bien con la optimización, pero tan pronto como apaga la optimización (quizás para la depuración), no se puede vincular.

Sin embargo, buenas noticias: ¡esta falla se solucionó en C ++ 17! Sin embargo, el enfoque es un poco complicado: en C ++ 17, las variables miembro estáticas constexpr están implícitamente en línea . La aplicación en línea a las variables es un concepto nuevo en C ++ 17, pero efectivamente significa que no necesitan una definición explícita en ninguna parte.

¿No es la solución más elegante cambiar la char[]:

static constexpr char * baz = "quz";

De esta manera podemos tener la definición / declaración / inicializador en 1 línea de código.

Mi solución para el enlace externo de los miembros estáticos es usar constexprcaptadores de miembros de referencia (que no se encuentra con el problema que @gnzlbg planteó como un comentario a la respuesta de @deddebme).
Este modismo es importante para mí porque odio tener múltiples archivos .cpp en mis proyectos e intento limitar el número a uno, que consiste en nada más que #includeuna main()función.

// foo.hpp
struct foo {
  static constexpr auto& baz() { return "quz"; }
};

// some.cpp

  auto sz = sizeof(foo::baz()); // sz == 4

  auto& foo_baz = foo::baz();  // note auto& not auto
  auto sz2 =  sizeof(foo_baz);    // 4
  auto name = typeid(foo_baz).name();  // something like 'char const[4]'

En mi entorno, gcc vesion es 5.4.0. Agregar "-O2" puede corregir este error de compilación. Parece que gcc puede manejar este caso cuando solicita la optimización.