¿Cuál es la diferencia en el comportamiento indefinido entre C++ 03 y C++ 11?

Question

El nuevo estándar tiene un comportamiento indefinido diferente del anterior. Las nuevas reglas de secuenciación, por ejemplo, significan que algunas operaciones aritméticas que solían estar indefinidas (por razones tales como escrituras múltiples entre puntos de secuencia) ahora están definidas.

Entonces, ¿qué necesitamos aprender nuevamente sobre el comportamiento indefinido?

Answer 1

En mi opinión, las nuevas reglas son más complejas de describir y comprender. Por ejemplo, considero que:

int x = 12; 
x = x++ + 1; // undefined behaviour 
x = ++x + 1; // valid 

Yo sugeriría que simplemente evitar múltiples efectos secundarios a la misma variable en la misma expresión que es una regla simple de entender. AFAIK C++ 0X cambió algunos casos que en el pasado eran un comportamiento indefinido y que ahora son usos legales (por ejemplo, la segunda de las dos expresiones anteriores), pero recuerde que siempre habrá una diferencia entre lo que es legal y lo que es moral ;-) ... nadie te está forzando a usar tales cosas.

En realidad, en el caso anterior parece que la validez de la segunda expresión ocurrió involuntariamente como un efecto secundario de la fijación de otro problema (# 222) en el idioma. La decisión fue hacer válida la expresión porque se consideró que cambiar algo de UB a bien definido no iba a causar ningún daño. Sin embargo, creo que si bien esto no causó ningún daño a los programas (donde, por supuesto, UB es el peor problema posible), en realidad dañó el lenguaje en sí ... cambiando una regla que ya era compleja de explicar y comprender. uno aún más oscuro.

IMO C++ continúa con su evolución natural de C a un lenguaje en el que un montón de buenas y lógicas afirmaciones pueden hacer cosas maravillosas ... y en las que otro grupo igualmente guapo, igual de agradable e igualmente lógico las declaraciones pueden hacer explotar su computadora en su lugar.

Answer 2

C++ 0x cambia una cantidad de casos no definidos previamente a ahora casos condicionalmente admitidos. La semántica es:

• Si la implementación no soporta la característica compatible condicionalmente, se debe documentar eso y debe emitir un diagnóstico para un programa que lo viola.
• Si la implementación lo hace compatible con, debe comportarse según los requisitos adicionales que el estándar establece en él. Por ejemplo, el estándar podría decir que algo tiene soporte condicional con semántica definida por la implementación. De ser así, la implementación deberá documentar cómo admite la característica.

Un caso popular que previamente no estaba definido es cuando pasa un argumento de tipo de clase que tiene un constructor no trivial copia, un movimiento contructor no trivial, o un destructor no trivial aunque un parámetro de la función de puntos suspensivos. Esto ahora está soportado de forma condicional, con semántica definida por la implementación.