uso sirve que programa para lenguaje iteradores iterador ejemplos c++ c optimization

sirve - que es un iterador c++



¿Qué es exactamente la regla "como si"? (2)

¿Cuál es la regla " como si "?

La regla " como si " básicamente define qué transformaciones puede realizar una implementación en un programa legal de C ++. En resumen, todas las transformaciones que no afectan el " comportamiento observable " de un programa (ver más abajo para una definición precisa) están permitidas.

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 el Estándar esta regla?

El estándar C ++ 11 introduce la regla " como si " en el párrafo 1.9 / 1:

Las descripciones semánticas en este estándar internacional definen una máquina abstracta no determinista parametrizada. Esta Norma Internacional no exige ningún requisito sobre la estructura de implementaciones conformes. En particular, no necesitan copiar o emular la estructura de la máquina abstracta. Por el contrario, se requieren implementaciones adecuadas para emular (solo) el comportamiento observable de la máquina abstracta como se explica a continuación.

Además, una nota explicativa 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 se hubiera obedecido, en la medida en que pueda determinarse 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é manda la regla exactamente?

El párrafo 1.9 / 5 especifica más:

Una implementación conforme que ejecute un programa bien formado debe 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 dicha ejecución contiene una operación no definida, esta Norma Internacional no exige que la implementación ejecute 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 resultados posibles de ejecutar un programa que contiene un comportamiento indefinido no están restringidos. Esto se hace explícito en el Párrafo 1.9 / 4 también:

Algunas otras operaciones se describen en esta norma internacional como indefinidas (por ejemplo, el efecto de intentar modificar un objeto const). [Nota: Esta Norma Internacional no impone requisitos sobre el comportamiento de los programas que contienen un comportamiento indefinido . -finalizar nota]

Finalmente, con respecto a la definición de " comportamiento observable ", el párrafo 1.9 / 8 dice lo siguiente:

Los requisitos mínimos en 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 los archivos serán idénticos a uno de los resultados posibles que la ejecución del programa de acuerdo con la semántica abstracta habría producido.

- La dinámica de entrada y salida de los dispositivos interactivos se llevará a cabo de tal manera que la salida de solicitud 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 la real. - nota final ]

¿Hay situaciones en las que esta regla no se aplica?

Según mi leal saber y entender, la única excepción a la regla " como si " es la elisión 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 copia / movimiento de un objeto de clase, incluso si el constructor seleccionado para la operación de copiar / mover y / o el destructor para el objeto tienen efectos secundarios . [...]

Como dice el título,

¿Qué es exactamente la regla "como si"?

Una respuesta típica que se obtendría es:

La regla que permite todas y cada una de las transformaciones de código que no cambian el comportamiento observable del programa

De vez en cuando, seguimos obteniendo comportamientos de ciertas implementaciones que se atribuyen a esta regla. Muchas veces erróneamente. Entonces, ¿qué es exactamente esta regla? El estándar no menciona claramente esta regla como una sección o párrafo, entonces, ¿qué es exactamente lo que cae dentro del alcance de esta regla? Para mí, parece una zona gris que no está definida en detalle por el estándar. ¿Puede alguien explicar los detalles citando las referencias del estándar?

Nota: etiquetar esto como C y C ++ ambos, porque es relevante para ambos idiomas.


En C11, la regla nunca se llama con ese nombre. Sin embargo, C, al igual que C ++, define el comportamiento en términos de máquina abstracta. La regla de si-si está en C11 5.1.2.3p6 :

  1. Los requisitos mínimos en una implementación conforme son:

    • Los accesos a objetos volatile se evalúan estrictamente de acuerdo con las reglas de la máquina abstracta.
    • Al finalizar el programa, todos los datos escritos en los archivos serán idénticos al resultado que la ejecución del programa de acuerdo con la semántica abstracta habría producido.
    • La dinámica de entrada y salida de los dispositivos interactivos se llevará a cabo como se especifica en 7.21.3 . La intención de estos requisitos es que la salida sin buffer o de buffer de línea aparezca tan pronto como sea posible, para garantizar que los mensajes de aviso aparezcan realmente antes de que un programa espere la entrada.

    Este es el comportamiento observable del programa.