c++ - Entendiendo la regla de "como si", "el programa fue ejecutado como está escrito"

compiler-optimization

Question

Estoy tratando de entender la regla como si . Según cppreference :

La regla de si
Permite cualquier y todas las transformaciones de código que no cambien el comportamiento observable del programa.

Explicación
Al compilador de C ++ se le permite realizar cualquier cambio en el programa siempre que lo siguiente siga siendo verdadero: [...]

Es difícil para mí entender el segundo consejo de la sección de Explicación:

2) Al finalizar el programa, los datos escritos en los archivos son exactamente como si el programa se ejecutara como está escrito.

Simplemente no entiendo lo que significa "el programa fue ejecutado como está escrito".

Answer 1

El lunes, su jefe entra a su oficina y dice "Necesito el archivo A en mi escritorio para el jueves y el archivo B en mi escritorio el viernes". Primero describe las cosas que quiere en el archivo A y cómo piensa que debes hacerlas y luego describe las cosas que quiere en el archivo B.

En la mente de su jefe, primero hará las cosas para el archivo A, colocará ese archivo en su escritorio el jueves, luego trabajará en el archivo B y lo terminará el viernes. Pero se da cuenta de que tendría más sentido comenzar a trabajar en el archivo B antes, incluso antes del archivo A. No hay razón para que su jefe lo sepa, todo lo que le importa es recibir A el jueves y B el viernes. También se da cuenta de que la forma en que sugirió se puede mejorar, por lo que adopta un enfoque ligeramente diferente para generar la información requerida.

En esta analogía, el jefe es un código C ++ y usted es el compilador. Es legal que el compilador reorganice las operaciones (trabajar en los archivos en otro orden) siempre que el comportamiento observable (colocar archivos en el escritorio del jefe) sea el mismo. De manera similar, el compilador es libre de realizar cualquier transformación (utilizando un enfoque diferente al descrito por el jefe) en el código que preserva el comportamiento observable.

En particular, "como si el programa se ejecutara como está escrito" significa "como si hiciera el trabajo exactamente como su jefe le indicó" (incluso si hizo algo diferente).

Answer 2

Una característica importante de la regla citada es que especifica un conjunto mínimo de requisitos para que una implementación sea conforme, pero de ninguna manera implica que esos requisitos sean suficientes para cualquier aplicación en particular, ni que algunas aplicaciones no necesiten implementaciones para ofrecer. Garantias mas fuertes. Supongamos que el procedimiento para realizar y registrar los resultados de una sola prueba sería:

1. Hacer el experimento
2. Anote el resultado medido.
3. Desbloquear la caja fuerte
4. Ponga el papel con las medidas en la caja fuerte.
5. Bloquea la caja fuerte.

Si a uno se le dan tres pruebas para realizar, uno podría realizar los cinco pasos anteriores en orden para cada prueba, pero cualquiera de las siguientes secuencias de pasos también podría ser aceptable:

1. Hacer experimento # 1
2. Anote el resultado medido en el papel # 1
3. Hacer experimento # 2
4. Anote el resultado medido en el papel # 2
5. Hacer experimento # 3
6. Anote el resultado medido en el papel # 3
7. Desbloquear la caja fuerte
8. Pon el papel # 1 en la caja fuerte
9. Pon el papel # 2 en la caja fuerte
10. Pon el papel # 3 en la caja fuerte
11. Cerrar la caja fuerte

o - para evitar tener que realizar un seguimiento de tres documentos a la vez:

1. Hacer experimento # 1
2. Anote el resultado medido en el papel # 1
3. Desbloquear la caja fuerte
4. Pon el papel # 1 en la caja fuerte
5. Hacer experimento # 2
6. Anote el resultado medido en el papel # 2
7. Pon el papel # 2 en la caja fuerte
8. Hacer experimento # 3
9. Anote el resultado medido en el papel # 3
10. Pon el papel # 3 en la caja fuerte
11. Cerrar la caja fuerte

Si todo sale como se espera, los tres enfoques serían equivalentes. Sin embargo, si el segundo experimento pudiera salir mal y destruir los documentos que se encuentran sobre el escritorio, usar el segundo enfoque podría perder los resultados del primer experimento, un resultado que no habría ocurrido si el procedimiento detallado se hubiera realizado seguido. Peor aún, si el tercer experimento realmente sale mal y destruye todo lo que no está encerrado en la caja fuerte, el tercer enfoque correría el riesgo de perder todo lo que estaba en la caja fuerte, incluso contenido no relacionado con los experimentos.

En algunos casos, el segundo o tercer enfoque puede ser apropiado. En algunos, no lo haría. Juzgar si esos enfoques son apropiados requeriría conocer los riesgos que plantean los experimentos, el contenido de la caja fuerte y muchos otros factores.

Los autores del Estándar no pueden saber todo lo necesario para juzgar qué garantías serán necesarias para qué aplicaciones. En su lugar, confían en los productores y usuarios de varias implementaciones para reconocer qué garantías se necesitarán para cumplir de manera segura y eficaz lo que sea necesario.