Здравствуйте, Кодт, Вы писали:

C>>Оч. странно. Ведь когда внутри скобки есть 2 операнда, всегда можно сказать, какой будет вычислен первым, а какой — вторым?!!
К>Кому можно сказать?
Ладно с параметрами — функций не так важно. Фиг с ними.
Но вот когда есть выражение:
(a + b)
Ведь можно с точностью сказать, что a будет вычислено раньше b ?

К>Ну хорошо, давай посмотрим на такой пример
K> --------
К>cos, sin — это встроенные (intrinsic) функции, компилятор заменит их на команды FPU. Очевидно, что результат вычисления можно сразу положить в две ячейки стека, не отвлекаясь на вычисление sqrt(x*y).
Ясно.
И всё же, по-моему весьма спорное решение сделать такой "жест доброй воли" оптимизатору в ущерб переносимости и "багоустойчивости" C++.
Пусть компилятор выворачивается как хочет. Можно в качестве оптимизации перевернуть порядок следования параметров в локальных вызовах.

К>А насчёт камней в огороды... Не бегай в валенках по конькобежной дорожке, так и не упадёшь.
Это понятно. Но никто не мешает подумать о том, как могло бы быть лучше.

---

Получается, что перед вызовом функции в переносимом коде всегда нужно вычислить аргументы зарание, если требуется жёсткая последовательность?

// вместо
process_ab(calc_a(), calc_b());
// нужно писать
const a_t& a = calc_a();
const b_t& b = calc_b();
process_ab(a, b);

// а также вместо
if (a())
  if (b())
      if (c())
           d();
// нельзя писать
a() && b() && c() && d(); ?

Здравствуйте, Кодт, Вы писали:

К>Если бы здесь operator++ был функцией, перегруженной для пользовательского типа, то точка следования появилась бы — вход в оператор++, выход из оператора, вход в следующий оператор++ — но порядок был бы неспецифицирован.

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

Здравствуйте, Chez, Вы писали:

C>Здравствуйте, Кодт, Вы писали:

C>Ладно с параметрами — функций не так важно. Фиг с ними.
C>Но вот когда есть выражение:
C>(a + b)
C>Ведь можно с точностью сказать, что a будет вычислено раньше b ?

Нет.

C>Получается, что перед вызовом функции в переносимом коде всегда нужно вычислить аргументы зарание, если требуется жёсткая последовательность?
C>

C>// вместо
C>process_ab(calc_a(), calc_b());
C>// нужно писать
C>const a_t& a = calc_a();
C>const b_t& b = calc_b();
C>process_ab(a, b);
C>

Получается так

C>

C>// а также вместо
C>if (a())
C>  if (b())
C>      if (c())
C>           d();
C>// нельзя писать
C>a() && b() && c() && d(); ?
C>

А вот это можно.
Для оператора && есть sequence point после вычисления первого операнда.
Более того первым будет левый. Более того если результат false, правый
не вычисляется.

Лазар

Здравствуйте, Chez, Вы писали:

C>Но вот когда есть выражение:
C>(a + b)
C>Ведь можно с точностью сказать, что a будет вычислено раньше b ?

Нет, нельзя. Потому что вычисление b не обусловлено вычислением a.
Можешь помыслить a+b как синтаксический сахар над operator+(a,b).

К>>Ну хорошо, давай посмотрим на такой пример
K>> --------
К>>cos, sin — это встроенные (intrinsic) функции, компилятор заменит их на команды FPU. Очевидно, что результат вычисления можно сразу положить в две ячейки стека, не отвлекаясь на вычисление sqrt(x*y).
C>Ясно.
C>И всё же, по-моему весьма спорное решение сделать такой "жест доброй воли" оптимизатору в ущерб переносимости и "багоустойчивости" C++.
C>Пусть компилятор выворачивается как хочет. Можно в качестве оптимизации перевернуть порядок следования параметров в локальных вызовах.

К>>А насчёт камней в огороды... Не бегай в валенках по конькобежной дорожке, так и не упадёшь.
C>Это понятно. Но никто не мешает подумать о том, как могло бы быть лучше.

В других языках порядок может быть прибит гвоздями. В С++ оговорено, что он не прибит.

C>

---

C>Получается, что перед вызовом функции в переносимом коде всегда нужно вычислить аргументы зарание, если требуется жёсткая последовательность?

Да.

C>// а также вместо
C>if (a())
C>  if (b())
C>      if (c())
C>           d();
C>// нельзя писать
C>a() && b() && c() && d(); ?

В отношении встроенных операторов , && || ?: гарантируется, что между первым и вторым операндами есть точка следования.
И более того, их деятельность совпадает с соответствующими конструкциями if-then-else, т.е. от вычисления первого операнда зависит, будет ли вычисляться второй.