Источники недетерминизма [закрыто]

Если ваши выходные данные зависят от адреса, выделенного в куче:

int main(int argc, char* argv[])
{
   printf("%p", malloc(42));
   return 0;
}

Для каждого запуска malloc() может возвращать другой виртуальный адрес, не говоря уже о NULL в случае неудачного выделения.

Если ваша программа использует float / double, результат может отличаться, если в какой-то архитектуре есть переключение контекста.

В x86 FPU использует расширенную точность для промежуточного результата, но при сохранении в памяти (что происходит при переключении контекста либо процесса, либо потока) такая точность теряется. Это могло привести к небольшому расхождению результата (мы обнаружили такую ​​проблему в нашей программе). Один из способов избежать этой проблемы — попросить компилятор использовать не FPU, а SSE для операций с плавающей запятой.

http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html

Использование значения указателя вместо того, на что он указывает, всегда приводит к интересным результатам.

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

• Входы из сети/интернета.
• дата/время

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

• Использование неинициализированной памяти.
• Состояние гонки.
• Какая-то непонятная комбинация всего вышеперечисленного.

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

Любое неопределенное поведение. то есть: потребуется сотни страниц, чтобы объяснить все возможные источники изменения вывода. Попробуйте выполнить отладку, чтобы найти , где происходит изменение, или прочитать некоторые спецификации C++.