Требуется ли согласованное поведение, определяемое реализацией, между запусками в C ++?

Конечно, если реализация документирует, когда именно поведение изменяется при разных запусках, это нормально. Обратите внимание, что поведение, определяемое реализацией, является частью параметров абстрактной машины:

Семантические описания в этом международном стандарте определяют параметризованную недетерминированную абстрактную машину.

Некоторые аспекты и операции абстрактной машины описаны в этом международном стандарте как определяемые реализацией (например, sizeof (int)). Они составляют параметры абстрактной машины. Каждая реализация должна включать документацию, описывающую ее характеристики и поведение в этих отношениях. Такая документация должна определять экземпляр абстрактной машины, который соответствует этой реализации (далее именуется «соответствующий экземпляр»).

Это не позволяет изменить поведение за один запуск компилятора. Но между разными запусками компилятора компилятор может использовать другую соответствующую абстрактную машину, которая отличается разными значениями, определяемыми реализацией, в зависимости от того, что определено реализацией. Параметры командной строки, такие как -Wall (который изменяет набор диагностических сообщений, определяемый реализацией), являются наиболее распространенным примером этого. Это отличие от неопределенного поведения в дополнение к требованиям документации. Неуказанное поведение гораздо менее ограничительно:

Некоторые другие аспекты и операции абстрактной машины описаны в этом международном стандарте как неуказанные (например, порядок оценки аргументов функции). По возможности, этот международный стандарт определяет набор допустимого поведения. Они определяют недетерминированные аспекты абстрактной машины. Таким образом, экземпляр абстрактной машины может иметь более одной возможной последовательности выполнения для данной программы и данного ввода.

Один из примеров, который я могу придумать, это то, что программа использует представление чисел с прямым или обратным порядком байтов. Я считаю, что это определенно будет считаться поведением, определяемым реализацией.

На некоторых микросхемах, например некоторых микросхемах ARM, можно переключать режимы во время выполнения, поэтому вам может потребоваться компилятор, который может создавать программу, которая будет работать в любом режиме, что означает, что у вас есть определенное реализацией поведение, которое потенциально может отличаться при каждом запуске в зависимости от по внешним настройкам.

Точно так же, я думаю, вы могли бы написать компилятор, который производил бы как 32-, так и 64-разрядные компиляции одной и той же программы - и режим, который он выполнял, можно было бы определить во время выполнения. Опять же, в документации должно быть указано, что ints были 32-битными или 64-битными, в зависимости от того, как вы его запускали.

Честно говоря, я не вижу, чтобы кто-то делал что-либо из этих вещей, но они оба звучат смутно правдоподобными примерами того, о чем вы просили, и я не понимаю, почему они не будут законными в соответствии со стандартом, если документация должным образом задокументировал природу зависимого от системы поведения.

Средства поведения, определенные реализацией

Неопределенное поведение, при котором каждая реализация документирует, как был сделан выбор.

Создатели компилятора должны обязательно задокументировать поведение конкретной программной конструкции для конкретной реализации.

..... таким образом, что он различается между разными запусками одной и той же скомпилированной программы с одними и теми же входными данными?

Нету!

Например, разрешено ли реализации говорить «это поведение по выходным, а в противном случае» и реализовывать поведение в соответствии с таким утверждением?

Я не уверен, но думаю, что ответ - нет.

IIRC, system () должен существовать, но с учетом поведения, определенного реализацией. Что-то вроде system ("ls | grep foo"), естественно, будет иметь разные эффекты в зависимости от того, может ли ваша система выполнять что-то, называемое ls, которое может различаться между запусками. И даже на довольно нормальной машине UNIX, где ls и grep делают то, что вы ожидаете, и не удаляются, результат по-прежнему будет зависеть от существования файла с foo в имени, который, безусловно, будет иметь возможность варьироваться время, и откуда программа выполняется и т. д. Это просто зависит от того, где вы проводите линию «одинаковых входных данных». Если машина находится в абсолютно идентичном состоянии, вы можете ожидать идентичного поведения, но никакие два прогона не приведут к тому, что машина действительно будет в педантически идентичном состоянии. (Даже температура процессора на совершенно идентичных машинах может привести к некоторому дросселированию, которое изменяет победителя некоторого состояния гонки, что явно приводит к другому поведению вашей программы.)

Гарантии - это то, что задокументировал компилятор. Различные флаги компилятора или другое состояние компьютера во время компиляции могут повлиять на то, как компилятор / оптимизатор обрабатывает вашу программу, и это может повлиять на результат. С флагами компилятора, имеющими наибольшее влияние (один и тот же компилятор может использоваться для генерации 32- и 64-битных программ в 64-битной среде, в двух прогонах требования к выравниванию могут различаться).

Вы можете ожидать, что в большинстве случаев разработчик предоставит некоторые базовые гарантии поведения реализации и программы, которую она генерирует для данного набора параметров компилятора / компоновщика. Даже если нагрузка на систему может повлиять на то, насколько оптимизатор может работать с вашей программой - некоторым оптимизаторам будет выделено некоторое ограниченное время - это не должно изменить ожидаемого поведения.

Обратите внимание, что, хотя нет никаких гарантий, было бы сложно продать компилятор, который генерирует код с различным поведением в зависимости от несвязанных параметров, таких как положение луны относительно звезд.

rand(3) в <stdlib.h> можно вызывать из C ++, не знаю, какая часть библиотеки C включена в «стандартный C ++», но, безусловно, есть некоторый соответствующий стандартам механизм для генерации случайных чисел.

time(3) в <time.h> возвращает текущее время; та же история с C ++ и вызовом библиотеки C.