¿Qué es la regla " como si "?
La regla " como si " básicamente define qué transformaciones puede realizar una implementación en un programa C ++ legal. En resumen, se permiten todas las transformaciones que no afecten el " comportamiento observable " de un programa (ver más abajo para una definición precisa).
El objetivo es dar a las implementaciones libertad para realizar optimizaciones siempre que el comportamiento del programa siga siendo compatible con la semántica especificada por el estándar C ++ en términos de una máquina abstracta.
¿Dónde introduce la Norma esta regla?
El estándar C ++ 11 introduce la regla " como si " en el párrafo 1.9 / 1:
Las descripciones semánticas de esta Norma Internacional definen una máquina abstracta no determinista parametrizada. Esta Norma Internacional no impone ningún requisito sobre la estructura de las implementaciones conformes. En particular, no necesitan copiar ni emular la estructura de la máquina abstracta. Más bien, se requieren implementaciones conformes para emular (solo) el comportamiento observable de la máquina abstracta como se explica a continuación.
Además, una nota explicativa a pie de página agrega:
Esta disposición a veces se denomina la regla "como si" , porque una implementación es libre de ignorar cualquier requisito de esta Norma Internacional siempre que el resultado sea como si el requisito se hubiera cumplido, en la medida en que se pueda determinar a partir del comportamiento observable. Del programa. Por ejemplo, una implementación real no necesita evaluar parte de una expresión si puede deducir que su valor no se usa y que no se producen efectos secundarios que afecten el comportamiento observable del programa.
¿Qué exige la regla exactamente?
El párrafo 1.9 / 5 especifica además:
Una implementación conforme que ejecuta un programa bien formado producirá el mismo comportamiento observable que una de las posibles ejecuciones de la instancia correspondiente de la máquina abstracta con el mismo programa y la misma entrada . Sin embargo, si tal ejecución contiene una operación no definida, esta Norma Internacional no impone ningún requisito a la implementación que ejecuta ese programa con esa entrada (ni siquiera con respecto a las operaciones que preceden a la primera operación no definida).
Vale la pena enfatizar que esta restricción se aplica cuando se "ejecuta un programa bien formado" solamente, y que los posibles resultados de ejecutar un programa que contiene un comportamiento indefinido no están restringidos. Esto también se hace explícito en el párrafo 1.9 / 4:
Algunas otras operaciones se describen en esta Norma Internacional como indefinidas (por ejemplo, el efecto de intentar modificar un objeto constante). [Nota: Esta Norma Internacional no impone requisitos sobre el comportamiento de los programas que contienen un comportamiento indefinido . —Nota final]
Por último, con respecto a la definición de " comportamiento observable ", el párrafo 1.9 / 8 dice lo siguiente:
Los requisitos mínimos para una implementación conforme son:
- El acceso a objetos volátiles se evalúa estrictamente de acuerdo con las reglas de la máquina abstracta.
- Al finalizar el programa, todos los datos escritos en archivos serán idénticos a uno de los posibles resultados que habría producido la ejecución del programa de acuerdo con la semántica abstracta.
- La dinámica de entrada y salida de los dispositivos interactivos se llevará a cabo de tal manera que la salida de avisos se entregue realmente antes de que un programa espere la entrada. Lo que constituye un dispositivo interactivo está definido por la implementación.
Estos colectivamente se conocen como el comportamiento observable del programa . [ Nota : Cada implementación puede definir correspondencias más estrictas entre la semántica abstracta y real. - nota final ]
¿Hay situaciones en las que esta regla no se aplica?
Hasta donde yo sé, la única excepción a la regla " como si " es la elisión de copiar / mover, que está permitida aunque el constructor de copia, el constructor de movimiento o el destructor de una clase tengan efectos secundarios. Las condiciones exactas para esto se especifican en el Párrafo 12.8 / 31:
Cuando se cumplen ciertos criterios, una implementación puede omitir la construcción de copiar / mover de un objeto de clase, incluso si el constructor seleccionado para la operación de copiar / mover y / o el destructor del objeto tienen efectos secundarios . [...]