c++ - saber - Unión de secuencia inicial común con primitiva.

polinomios irreducibles ejercicios resueltos

Question

Estoy tratando de entender mejor un descubrimiento bastante sorprendente con respecto a las uniones y la regla de secuencia inicial común. La regla de secuencia inicial común dice (class.mem 23):

En una unión de diseño estándar con un miembro activo del tipo de estructura T1, se permite leer un miembro de datos no estáticos m de otro miembro de la unión del tipo de estructura T2 siempre que m forme parte de la secuencia inicial común de T1 y T2; el comportamiento es como si el miembro correspondiente de T1 fuera nominado.

Entonces, dado:

struct A {
int a;
double x;
};
struct B {
int b;
};
union U {
A a;
B b;
};
U u;
u.a = A{};
int i = u.b.b;

Este es un comportamiento definido y i debería tener el valor 0 (porque A y B tienen un CIS de su primer miembro, un int ). Hasta ahora tan bueno. Lo confuso es que si B es reemplazado por simplemente un int:

union U {
A a;
int b;
};
...
int i = u.b;

Según la definición de secuencia inicial común:

La secuencia inicial común de dos tipos de estructuras de diseño estándar es ...

Por lo tanto, los CIS solo pueden aplicarse entre dos estructuras de diseño estándar. Y a la vez:

Una estructura de diseño estándar es una clase de diseño estándar definida con la estructura de clave de clase o la clase de clave de clase.

Así que un tipo primitivo definitivamente no califica; es decir, no puede tener un CIS con nada, por lo que A no tiene CIS con un int . Por lo tanto, el estándar dice que el primer ejemplo es el comportamiento definido, pero el segundo es UB. Esto simplemente no tiene ningún sentido para mí en absoluto; el compilador intuitivamente es al menos tan restringido con un tipo primitivo como con una clase. Si esto es intencional, ¿hay alguna rima o razón (quizás relacionada con la alineación) de por qué esto tiene sentido? ¿Es posiblemente un defecto?

Answer 1

ninjalj tiene razón : el propósito de esta regla es admitir uniones etiquetadas (con etiquetas en la parte delantera). Si bien uno de los tipos admitidos en una unión de este tipo podría ser sin estado (aparte de la etiqueta), este caso se puede abordar de manera trivial al hacer una estructura que contenga solo la etiqueta. Por lo tanto, no es necesario extender la regla más allá de las estructuras, y de forma predeterminada, tales excepciones al comportamiento indefinido (similar a un aliasing estricto en este caso) se deben mantener al mínimo por las razones habituales de optimización y flexibilidad de la futura estandarización.