К слову. Все современные компиляторы самостоятельно будут использовать сдвиг вместо деления когда это оправдано, так что (x*5)/8 совершенно равнозначно (х*5)>>3, но читается проще.

Возможно, но иногда удивляешся коду, который нагенерил "современный" компилятор...

А, вот тут я с Вами не согласен. Насколько я помню (поправьте, если я не прав): раставленные в выражении (x*5)/8 скобочки никак не определяют последовательность выполнения операций. Поскольку приоритеты операций * и / одинаковые, то выражение (x*5)/8 с точки зрения компилятора в соответствии со стандартом эквивалентно x*5/8 или даже x*(5/8). Компилятор вправе на этапе трансляции вычислить часть выражения, если операнды - константы. Но, поскольку 5/8 равно нулю, то можно получить результат далёкий от ожидаемого...
При вычислении выражения (х*5)>>3 последовательность вычислений однозначно определена приоритетами.

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

Проверил живьём на максимальном уровне оптимизации выражение
превратилось в

Всё как и ожидалось сначала умножил на 5 (хитро сложив и сдвинув), а потом поделил на 8 (сдвинув направо на 3).
Стандарта в части скобочек не могу процитировать, но полагаю что scifi близок к истине.

Я не утверждал, что скобки "ни на что не влияют". Например в выражении (х*5)>>3 они (скобки) очень даже "влияют". А, вот, в выражении (x*5)/8 компилятор вправе их игнорировать...
Пример попроще: выражение (х+2)-1. Как Вы думаете: компилятор сгенерирует 1) выполнение двух операций или 2) преобразует в х+(2-1) и, соответственно, вычислит на этапе трансляции (2-1) и, в конце концов, получим х+1 ?

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

Ну, если мне не верите, проверьте сами. По-вашему выражение (x*5)/8 даёт результат 0 вне зависимости от значения x. Это легко проверить. Или Вы хотите сказать, что результат выражения зависит от уровня оптимизации? Тогда это вообще нонсенс. Кому нужна оптимизация, коверкающая результат простейшего арифметического выражения? Не говоря уже о том, что это просто противоречит стандарту языка Си.

Добавление:
Да, в стандарте языка указаны случаи, в которых порядок вычисления не определён. Например, порядок вычисления аргументов функции. Или операндов побитового И или ИЛИ (& или |). Но (x*5)/8 - не тот случай. Стандарт чётко описывает, что сначала идёт умножение, а потом - деление (кстати, и без скобок тоже, по правилам приоритетов операторов). Причём умножение и деление происходят в "абстрактной машине". Что там нагенерит компилятор - его дело, лишь бы результат был бы такой же, как в "абстрактной машине". Как мы видели, он может нагенерить сдвиги и сложения. Или вообще подставить константу, если результат выражения известен на этапе компиляции.

Докажите что ли на конкретном примере кода и компилятора. А так - очередной "вредный совет" или версия.

Для себя уже давно доказал на разных компиляторах...
Вы хотите увидеть как x=(x-1)+2 превратится в x+=1 ???

То есть какой-то компилятор может "наплевать" на скобки? Какой?

Upd.
Проверил на IAR-е.
Сложения и вычитания костант, идущие друг за другом даже за скобками он упрощает. Потому как переполнения на них не влияют. А умножения и деления нет.

Сообщение отредактировал GetSmart - Jul 12 2011, 10:27

Как я понял, demiurg_spb и не намекает на то, что компилятор может наплевать на скобки. Напротив:

В данном случае перестановка скобок (x*5)/8 -> x*(5/8) очень даже изменяет суть, а потому компилятору не разрешена. Что мы и пытаемся объяснить Палычу.
Не соглашусь только, что компилятор применит оптимизацию "несомненно", так как видел немало тупых компиляторов.

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

Тут с Вами не соглашусь. Приоритет всех мультипликативных операций (*, /, %) одинаков.

В некоторых случаях - да, может "наплевать". Речь идёт о операциях с одинаковым приоритетом в скобках и за скобками. Нет времени искать точную формулировку в стандарте, но, по-памяти: "порядок выполнения операций может быть изменён, если это не приводит к изменению значения выражения". С учетом того, что при выполнении операций могут возникать всякие-разные "неприятности" (типа переполнения результата), то понятие "неизменный результат" становится очень расплывчатым, и тут - простор для трансляторописателей...

Было такое. Но это исключительно когда нет скобок. Не выдумывайте свою интерпретацию



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

По логике, это можно делать, когда перепонения при исполнении операций не могут повлиять на результат. То есть то же, что и в школьной математике, но с учётом ограниченности (временных) переменных. Это подходит к сложениям/вычитаниям, лог операциям, но не относится к сдвигам, умнодениям/делениям.

То есть кто-то может неправильно понять стандарт и, соответвственно, написать компилятор с глюком. Спасибо за напоминание об это очевидном факте.


Я имел в виду в данном конкретном выражении: (x*5)/8.


Нет нужды, я уже нашёл:



В случае с целыми беззнаковыми числами никакой расплывчатости нет:

Не разобравшись в ситуации, не давайте вредных советов. Вдруг неокрепшие умы всерьёз воспримут.

Действительно - признаю: в стандарте порядок операций может быть изменён, если нет скобок (т.е. нет Primary expressions, имеющих при вычислениях наивысший приоритет). Однако стандарт и тут оставляет "лазейку": абсолютно вся оптимизация отдана на откуп компиляторописателям. Забавно, что IAR оптимизирует даже при выключенной оптимизации. Например, выражение (x+1)+(y+1) оптимизирует до x+y+2