Когда оптимизация предусмотрена стандартом

[zHz00]

Оптимизация при компиляции часто представляет собой не благо, а проблему. Компилятор на своё усмотрение может выкинуть кусок кода, который счёл ненужным. Да, от этого есть некоторые методы защиты, типа использования volatile, но во многих случаях проще оптимизацию отключить, чем разбираться с её последствиями. Если у вас есть годный гайд по работе с оптимизацией в компиляторах си/си++, сообщите мне, пожалуйста.

Но есть случаи, когда даже с отключённой оптимизацией можно столкнуться с неожиданным поведением.

Один чувак отлаживал программу, и обнаружил странное поведение. Если написать:

if(var||func())//...

то программа работала неправильно. А если написать:

if(func()||var)//...

то программа работала как положено.

Неправильность первого варианта заключалась в том, что в первом случае функция func() просто не вызывалась, что влекло непредвиденные последствия. Причина была проста. Первый операнд операции "или" был истинным, поэтому компилятор не вычислял значение второго, а значит и не вызывал функцию. И правда, зачем тратить время, когда и так уже понятно, что общий результат будет истинным?

И это не оптимизация компилятора. Такое поведение предписывается стандартом. Например ISO/IEC 9899:TC3, пункт 6.5.14 (похоже, это какой-то черновик, но данный пункт одинаков во всех версиях) гласит:

... If the first operand compares unequal to 0, the second operand is not evaluated.

Про "или" я не знал, но я давно знал про такое поведение для оператора "и", поэтому для меня оказалось ожидаемо, что с "или" ситуация аналогична. Что же там говорится про "и"? Пункт 6.5.13:

... If the first operand compares equal to 0, the second operand is not evaluated.

То есть, для оператора "и" второй операнд не вычисляется, если первый оказался ложным. Такой вот подводный камень.

UPD. мне сообщили, что в си-шарп и питоне поведение такое же.

Comments

[Foul thing]

Удивительно, что для тебя это новость. Это даже на собеседованиях спрашивают.
Я всегда, когда пишу условия через || или &&, прикидываю, какое из них более "легкое" или наиболее вероятное, и ставлю такое первым, чтобы отсеять часть неудобных вычислений.

[Foul thing]

Кстати, не является ли твой ник Z-символикой?

[zHz00]

Foul thing,
>>Удивительно, что для тебя это новость

Век живи -- век учись. Ты лучше скажи, как пользоваться оптимизацией и не страдать.

>>какое из них более "легкое" или наиболее вероятное

Огого!

>>не является ли твой ник Z-символикой?

Чёт не знаю, как тебе ответить. Оставляю это на откуп твоей фантазии.

[RetXiRT suiR@ttig@$]

Стратегия Z.
Фильм World War Z.

[Xersareeth]

> мне сообщили, что в си-шарп и питоне поведение такое же
есть даже такой паттерн: var = var || 'default_value'

> Оставляю это на откуп твоей фантазии
Но это же очевидная H-символика) Впрочем, всегда есть опасность найти смысл там, где его нет =)

[Foul thing]

есть даже такой паттерн: var = var || 'default_value'

В сишарпе не работает, т.к. отсутствует неявное преобразование к bool.

Точнее, вот это сработает:
var a = true;
a = a || true;

А вот это - нет:
var a = 3;
a = a || 2;

Инты к булю не кастуются.

[RetXiRT suiR@ttig@$]

zHz - z-символика, Н-символика, опять z-символика.
HDoom - H-символика.
Альзо, таки ещё аниме Dragonball Z.