¿Qué hizo i = i ++ + 1; legal en C ++ 17?

Antes de comenzar a gritar un comportamiento indefinido, esto se enumera explícitamente en N4659 (C ++ 17)

  i = i++ + 1;        // the value of i is incremented

Sin embargo, en N3337 (C ++ 11)

  i = i++ + 1;        // the behavior is undefined

¿Qué cambió?

Por lo que puedo recopilar, de [N4659 basic.exec]

Excepto donde se indique, las evaluaciones de operandos de operadores individuales y de subexpresiones de expresiones individuales no están secuenciadas. [...] Los cálculos de valor de los operandos de un operador se secuencian antes del cálculo de valor del resultado del operador. Si un efecto secundario en una ubicación de memoria no se secuencia en relación con otro efecto secundario en la misma ubicación de memoria o un cálculo de valor utilizando el valor de cualquier objeto en la misma ubicación de memoria, y no son potencialmente concurrentes, el comportamiento no está definido.

Donde el valor se define en [N4659 basic.type]

Para tipos trivialmente copiables, la representación del valor es un conjunto de bits en la representación del objeto que determina un valor , que es un elemento discreto de un conjunto de valores definido por la implementación.

De [N3337 basic.exec]

Excepto donde se indique, las evaluaciones de operandos de operadores individuales y de subexpresiones de expresiones individuales no están secuenciadas. [...] Los cálculos de valor de los operandos de un operador se secuencian antes del cálculo de valor del resultado del operador. Si un efecto secundario en un objeto escalar no está secuenciado en relación con otro efecto secundario en el mismo objeto escalar o un cálculo de valor utilizando el valor del mismo objeto escalar, el comportamiento no está definido.

Asimismo, el valor se define en [N3337 basic.type]

Para tipos que se pueden copiar trivialmente, la representación del valor es un conjunto de bits en la representación del objeto que determina un valor , que es un elemento discreto de un conjunto de valores definido por la implementación.

Son idénticos excepto la mención de la concurrencia que no importa, y con el uso de la ubicación de la memoria en lugar del objeto escalar , donde

Los tipos aritméticos, los tipos de enumeración, los tipos de puntero, los tipos de puntero a miembros std::nullptr_ty las versiones calificadas por cv de estos tipos se denominan colectivamente tipos escalares.

Lo que no afecta el ejemplo.

De [N4659 expr.ass]

El operador de asignación (=) y los operadores de asignación compuesta se agrupan de derecha a izquierda. Todos requieren un lvalue modificable como su operando izquierdo y devuelven un lvalue que se refiere al operando izquierdo. El resultado en todos los casos es un campo de bits si el operando izquierdo es un campo de bits. En todos los casos, la asignación se secuencia después del cálculo del valor de los operandos derecho e izquierdo, y antes del cálculo del valor de la expresión de asignación. El operando derecho se secuencia antes del operando izquierdo.

De [N3337 expr.ass]

El operador de asignación (=) y los operadores de asignación compuesta se agrupan de derecha a izquierda. Todos requieren un lvalue modificable como su operando izquierdo y devuelven un lvalue que se refiere al operando izquierdo. El resultado en todos los casos es un campo de bits si el operando izquierdo es un campo de bits. En todos los casos, la asignación se secuencia después del cálculo del valor de los operandos derecho e izquierdo, y antes del cálculo del valor de la expresión de asignación.

La única diferencia es que la última oración está ausente en N3337.

Sin embargo, la última oración no debería tener ninguna importancia, ya que el operando izquierdo ino es "otro efecto secundario" ni "usar el valor del mismo objeto escalar", ya que la expresión id es un valor l.

En C ++ 11, el acto de "asignación", es decir, el efecto secundario de modificar el LHS, se secuencia después del cálculo del valor del operando derecho. Tenga en cuenta que esta es una garantía relativamente "débil": produce secuenciación sólo en relación con el cálculo del valor del RHS. No dice nada sobre los efectos secundarios que podrían estar presentes en el RHS, ya que la aparición de efectos secundarios no es parte del cálculo del valor . Los requisitos de C ++ 11 no establecen una secuencia relativa entre el acto de asignación y los efectos secundarios del RHS. Esto es lo que crea el potencial de UB.

La única esperanza en este caso son las garantías adicionales hechas por operadores específicos utilizados en RHS. Si el RHS usara un prefijo ++, las propiedades de secuenciación específicas de la forma de prefijo de ++habrían salvado el día en este ejemplo. Pero postfix ++es una historia diferente: no ofrece tales garantías. En C ++ 11, los efectos secundarios de =y el sufijo ++terminan sin secuenciarse entre sí en este ejemplo. Y eso es UB.

En C ++ 17 se agrega una oración adicional a la especificación del operador de asignación:

El operando derecho se secuencia antes del operando izquierdo.

En combinación con lo anterior, constituye una garantía muy sólida. Secuencia de todo lo que sucede en el lado derecho (incluidos los efectos secundarios) antes de todo lo que sucede en el lado izquierdo . Dado que la asignación real se secuencia después de LHS (y RHS), esa secuencia adicional aísla por completo el acto de asignación de cualquier efecto secundario presente en RHS. Esta secuenciación más fuerte es lo que elimina la UB anterior.

(Actualizado para tener en cuenta los comentarios de @John Bollinger).

Identificaste la nueva oración

El operando derecho se secuencia antes del operando izquierdo.

e identificó correctamente que la evaluación del operando izquierdo como un valor l es irrelevante. Sin embargo, secuenciado antes se especifica como una relación transitiva. Por lo tanto, el operando derecho completo (incluido el incremento posterior) también se secuencia antes de la asignación. En C ++ 11, solo se secuenciaba el cálculo del valor del operando derecho antes de la asignación.

En los estándares de C ++ más antiguos y en C11, la definición del texto del operador de asignación termina con el texto:

Las evaluaciones de los operandos no están secuenciadas.

Lo que significa que los efectos secundarios en los operandos no están secuenciados y, por lo tanto, un comportamiento definitivamente indefinido si usan la misma variable.

Este texto simplemente se eliminó en C ++ 11, dejándolo algo ambiguo. ¿Es UB o no? Esto se ha aclarado en C ++ 17 donde agregaron:

El operando derecho se secuencia antes del operando izquierdo.

Como nota al margen, en estándares aún más antiguos, todo esto quedó muy claro, ejemplo de C99:

El orden de evaluación de los operandos no está especificado. Si se intenta modificar el resultado de un operador de asignación o acceder a él después del siguiente punto de secuencia, el comportamiento no está definido.

Básicamente, en C11 / C ++ 11, se equivocaron cuando eliminaron este texto.

Esta es más información para las otras respuestas y la estoy publicando, ya que a menudo también se pregunta sobre el código a continuación .

La explicación en las otras respuestas es correcta y también se aplica al siguiente código que ahora está bien definido (y no cambia el valor almacenado de i):

i = i++;

El + 1es una cortina de humo y no está muy claro por qué el estándar utilizado en sus ejemplos, aunque sí la gente recuerda que discuten en las listas de correo antes de C ++ 11 que tal vez el + 1hecho una diferencia debido a forzar la conversión temprana lvalue en la derecha lado. Ciertamente, nada de eso se aplica en C ++ 17 (y probablemente nunca se aplicó en ninguna versión de C ++).