¿Se requiere un comportamiento definido en la implementación para ser consistente entre las ejecuciones en C++?

Question

¿Se permite implementar C++ conforme a las normas para implementar algún comportamiento que se dice que está definido en la implementación en el estándar de tal manera que es diferente entre diferentes ejecuciones del mismo programa compilado una vez con los mismos datos de entrada?

Por ejemplo, ¿se permite que una implementación diga "el comportamiento es esto los fines de semana y de lo contrario" e implemente el comportamiento de acuerdo con dicha afirmación? significa comportamiento definido

Answer 1

Implementación

especi Comportamiento fi cada en cada implementación documentos cómo se hace la elección

Es obligatoria para los autores de compiladores para documentar el comportamiento de una programación en particular construir para una implementación particular.

..... de tal manera que es diferente entre diferentes ejecuciones del mismo programa compilado una vez con los mismos datos de entrada?

Nopes!

Por ejemplo, ¿se permite que una implementación diga "el comportamiento es esto los fines de semana y de lo contrario" e implemente el comportamiento de acuerdo con dicha afirmación?

No estoy seguro, pero creo que la respuesta es no.

Answer 2

rand(3) en <stdlib.h> se puede llamar desde C++, no estoy seguro de qué parte de la biblioteca C se incluye en "C++ estándar", pero seguramente hay algún mecanismo conforme a las normas para generar números aleatorios.

time(3) en <time.h> devuelve la hora actual; misma historia con C++ y llamando a la biblioteca C.

Answer 3

Por supuesto, si la implementación documenta exactamente cuando el comportamiento cambia con diferentes ejecuciones, está bien. Observe que el comportamiento definido por la implementación es parte de los parámetros de la máquina abstracta:

Las descripciones semánticas en esta Norma Internacional definen un parametrizada no determinista máquina abstracta .

Ciertos aspectos y operaciones de la máquina abstracta se describen en esta Norma Internacional como definidos por la implementación (por ejemplo, sizeof (int)). Estos constituyen los parámetros de la máquina abstracta. Cada implementación debe incluir documentación que describa sus características y comportamiento en estos aspectos. Dicha documentación debe definir la instancia de la máquina abstracta que corresponde a esa implementación (a la que se hace referencia como la "instancia correspondiente" a continuación).

Esto no permite cambiar el comportamiento en una sola ejecución del compilador.Pero entre las diferentes ejecuciones del compilador, el compilador puede usar una máquina abstracta diferente correspondiente que difiere por diferentes valores definidos de implementación, de acuerdo con lo que definió la implementación. Los parámetros de línea de comando como -Wall (que cambia el conjunto de mensajes de diagnóstico definidos por la implementación) son el ejemplo más común de esto. Esta es una diferencia para el comportamiento no especificado además de los requisitos de documentación. El comportamiento no especificado es mucho menos restrictivo:

Algunos otros aspectos y operaciones de la máquina abstracta se describen en esta Norma Internacional como no especificados (por ejemplo, orden de evaluación de argumentos para una función). Donde sea posible, este Estándar Internacional define un conjunto de comportamientos permitidos. Estos definen los aspectos no deterministas de la máquina abstracta. Una instancia de la máquina abstracta puede así tener más de una secuencia de ejecución posible para un programa dado y una entrada dada.

Answer 4

IIRC, se requiere que el sistema() exista, pero se da un comportamiento definido de implementación. Algo así como el sistema ("ls | grep foo") naturalmente tendrá diferentes efectos en función de si su sistema puede ejecutar algo llamado ls, que puede variar entre ejecuciones. E incluso en una máquina UNIX bastante normal donde ls y grep hacen lo que cabría esperar y no se eliminan, el resultado dependerá de la existencia de un archivo con foo en el nombre, que sin dudas podrá variar a lo largo del tiempo. hora, y desde donde se ejecuta el programa, etc. Simplemente depende de dónde dibuje la línea de "los mismos datos de entrada". Si la máquina está en un estado perfectamente idéntico, entonces puede esperar un comportamiento idéntico, pero no habrá dos carreras que involucren a una máquina verdaderamente en un estado pedantemente idéntico. (Incluso la temperatura de la CPU en máquinas que, por lo demás, serían perfectamente idénticas, podría provocar un comportamiento de estrangulamiento que altere al ganador de alguna condición de carrera, lo que produce un comportamiento diferente del programa).

Answer 5

Un ejemplo en el que puedo pensar es si el programa usa representación endian grande o pequeña para números. Creo que esto ciertamente contaría como comportamiento definido de implementación.

En algunos chips, por ejemplo ciertos chips ARM es posible cambiar los modos en tiempo de ejecución así que puede querer un compilador que podría producir un programa que se ejecutaría en cualquier modo lo que significa que tiene un comportamiento definido de implementación que podría ser potencialmente diferente en cada ejecución dependiendo de la configuración externa.

De manera similar, supongo que podría escribir un compilador que produjera tanto 32 como 64 bits compilados del mismo programa, y ​​el modo que ejecutara podría determinarse en tiempo de ejecución. Una vez más, la documentación debería decir que las entradas eran de 32 bits o de 64 bits, dependiendo de cómo lo haya ejecutado.

Para ser honesto, no puedo ver a nadie haciendo estas cosas, pero ambos suenan vagamente plausibles ejemplos de lo que estaba pidiendo y no puedo ver por qué no serían legales bajo el estándar mientras ya que la documentación documentó adecuadamente la naturaleza del comportamiento dependiente del sistema.

Answer 6

Las garantías son las que el compilador ha documentado. Los diferentes indicadores del compilador o el estado diferente de la computadora en el momento de la compilación pueden afectar la forma en que el compilador/optimizador procesa su programa y eso puede tener un efecto en el resultado. Con los indicadores del compilador que tienen el mayor impacto (el mismo compilador se puede usar para generar programas de 32 y 64 bits en un entorno de 64 bits, en las dos ejecuciones los requisitos de alineación pueden diferir).

Puede esperar que en la mayoría de los casos el implementador proporcione algunas garantías básicas sobre el comportamiento de la implementación y el programa que genera para un conjunto dado de parámetros de compilador/enlazador. Incluso si la carga del sistema puede afectar cuánto puede funcionar el optimizador en su programa (algunos optimizadores tendrán un tiempo limitado) eso no debería cambiar el comportamiento esperado.

Tenga en cuenta que si bien no hay garantía, sería difícil comercializar un compilador que produce código con diferentes comportamientos dependiendo de parámetros no relacionados como la posición de la luna con respecto a las estrellas.