Почему #pragma optimize ("", off)

Ответ 1

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

Однако я бы счел гораздо более вероятным, что код просто глючит, имея Undefined Behavior. Оптимизатор предоставляет это и приводит к неправильному поведению или сбоям в работе. Без оптимизаций код "работает". И вместо того, чтобы находить и устранять основную проблему, кто-то "исправил" ее, отключив оптимизацию и оставив ее на этом.

Конечно, это примерно так же хрупко и обходные пути. Новое оборудование, новый патч ОС, новый патч компилятора, любой из них может сломать такое "исправление".

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

Ответ 2

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

Ответ 3

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

При написании драйверов устройств или другого низкоуровневого кода оптимизатор иногда производит вывод, который не взаимодействует с оборудованием правильно.

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

Это может также иллюстрировать, почему (как отмечает Анже) использование этой директивы должно быть четко документировано.

Ответ 4

Еще одна альтернативная причина для того, чтобы они были в кодовой базе... Ее авария.

Это очень удобный инструмент для отключения оптимизатора в определенном файле во время отладки - как упоминалось выше.

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