Результат трехчасовых поисков ошибки в проекте :)

← →
DiamondShark © (2007-12-10 19:14) [80]

> Palladin © (10.12.07 19:07) [75]
>
> он не должен себя вести, это от него ожидается

Так это проблемы ожидающего.

> я же не утверждаю, что это закон! я утверждаю, что это принято
> повсеместно,

Не принято. Примеры уже приводили.

> а тот факт что он себя так не ведет должен
> отражаться в документации

Это насилие над логикой: перечислять отсутствующие свойства.

← →
Gydvin © (2007-12-10 19:14) [81]

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

← →
DiamondShark © (2007-12-10 19:16) [82]

> Palladin © (10.12.07 19:13) [79]
>
> > Как он себя ведет - отражено в документации.
>
> ну так в том то и дело, как уже сказал DiamondShark это
> не отражено в документации, и ожидается принятое, человеческое.

Как уже сказал DiamondShark, принятое, человеческое совсем другое.

← →
@!!ex © (2007-12-10 19:16) [83]

> [79] Palladin © (10.12.07 19:13)

Да в том то и дело. Что НЕЛЬЗЯ ничего ожидать, если это не утверждено в стандарте.
Нет default значения. Есть НЕОПРЕДЕЛЕННОЕ значение. И когда программист этого не учитывает, получает:
"Прикол с борландовским Си, когда выражение с сайд-эффектами давало разные результаты в зависимости от ключей компилятора -- притча во языцех."[67]

← →
@!!ex © (2007-12-10 19:17) [84]

> [81] Gydvin © (10.12.07 19:14)

На примеры документация врядли есть. Но и обратной документации нету тоже.

← →
Gydvin © (2007-12-10 19:21) [85]

А негласные стандарты не учитываются?
Зачем переливать из пустого в порожнее и изыскивать то, что в природе не существует?

← →
@!!ex © (2007-12-10 19:22) [86]

> [85] Gydvin © (10.12.07 19:21)

Как можно в формализованной структуре учитывать неформализованные стандарты?

← →
guav © (2007-12-10 19:23) [87]

Ожидать определённый порядок выражений по разные стороны бинароного оператора - это то же что и ожидать определённый порядок оценки параметров функции.

← →
Gydvin © (2007-12-10 19:24) [88]

Хотябы тем что это все писалось людьми и для людей. Иначе разбродс...

← →
guav © (2007-12-10 19:30) [89]

> то же что и ожидать определённый порядок оценки параметров
> функции.

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

← →
@!!ex © (2007-12-10 19:31) [90]

> [88] Gydvin © (10.12.07 19:24)

Форт кем писался? :))

← →
Palladin © (2007-12-10 19:31) [91]

то, что я не верблюд вообще доказать сложно...

← →
Gydvin © (2007-12-10 19:34) [92]

> @!!ex © (10.12.07 19:31) [90]
> > [88] Gydvin © (10.12.07 19:24)Форт кем писался? :))

Ух ты доказательства нашлись :0)
И что там? Не смотрел язык

← →
guav © (2007-12-10 19:36) [93]

В С++ порядок оценивания гарантируется только для встроенных логических and и or, и оператора запятая (для and и or гарантирована также сокращённая оценка). Для остальных бинарных операторах ничего не подразумевается.
Может стоит посмотреть в справке Delphi насчёт логических операторов, для них тоже наверное гарантируется порядок, и там может указано и про остальные ?

← →
Григорьев Антон © (2007-12-10 19:39) [94]

Этот прикол с порядком операндов известен давно: http://www.delphikingdom.com/asp/viewitem.asp?catalogid=631

И в этом форуме мы его месяца четыре назад обсуждали. Тогда выяснилось, что в тестовом примере FreePascal, в отличие от Delphi, по умолчанию сначала вычислил первый аргумент, а затем второй, но когда при компиляции включили опцию совместимости с Delphi, то тоже вычислял сначала второй аргумент, потом первый.

← →
korneley © (2007-12-10 19:41) [95]

> @!!ex © (10.12.07 19:31) [90]
Чарльз Мур

← →
Anatoly Podgoretsky © (2007-12-10 19:43) [96]

Не пиши функции с побочными эффектами, поскольку они функциями и не являются, а так функционалами и чего тогда от них ожидать?
А порядок определен, Romkin уже сделал выписку из справки. Повторю в более полном варианте.

> An operator with higher precedence is evaluated before an
> operator with lower precedence, while operators of equal
> precedence associate to the left. Hence the expression
>
> X + Y * Z
>
> multiplies Y times Z, then adds X to the result; * is performed
> first, because is has a higher precedence than +. But
>
> X - Y + Z
>
> first subtracts Y from X, then adds Z to the result; - and
> + have the same precedence, so the operation on the left is performed first.

← →
Palladin © (2007-12-10 19:49) [97]

> Anatoly Podgoretsky © (10.12.07 19:43) [96]

DiamondShark сопротивляется и советует не путать теплое с мягким

← →
@!!ex © (2007-12-10 19:51) [98]

> [97] Palladin © (10.12.07 19:49)

Да не вопрос, раз в документации написано, то значит так и должно быть.
Лично я спорил не об этом. А о том, что если в документации этого НЕТ, значит ничего подразумевать НЕЛЬЗЯ.

← →
Mystic © (2007-12-10 19:52) [99]

> Anatoly Podgoretsky © (10.12.07 19:43) [96]

Порядок выполнения операций определен, но где же порядок вычисления операндов?

← →
@!!ex © (2007-12-10 19:53) [100]

> [99] Mystic © (10.12.07 19:52)

Кстати да...

← →
Palladin © (2007-12-10 19:56) [101]

> @!!ex © (10.12.07 19:51) [98]

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

← →
Anatoly Podgoretsky © (2007-12-10 20:00) [102]

> Порядок выполнения операций определен, но где же порядок
> вычисления операндов?

О каких операндах ты говоришь
ShowMessage(IntToStr(Funct1(Param) + Funct2(Param)));Когда у Funct1, Funct2 и у IntToStr по одному операнду.
Здесь единственная проблема, что это не функция, поскольку изменяет значения за пределами функции, в итоге побочные эффекты. По другому это не детерминированая "функция".

← →
@!!ex © (2007-12-10 20:06) [103]

> [101] Palladin © (10.12.07 19:56)

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

← →
Palladin © (2007-12-10 20:11) [104]

> @!!ex © (10.12.07 20:06) [103]

приведи

← →
@!!ex © (2007-12-10 20:30) [105]

> [104] Palladin © (10.12.07 20:11)

Что привести?

← →
Palladin © (2007-12-10 20:35) [106]

> @!!ex © (10.12.07 20:30) [105]

Более чем достаточное содержание документации, которое убедит меня в том, что я могу однозначно предсказывать поведение кода не делая при этом никаких домыслов. То есть я смело напишу a:=funct1(v)/funct2(v)
и буду уверен что выполнится funct1, а потом funct2, ведь я подразумеваю что выполнится funct1, а потом funct2. соответственно результат будет верен.

или ты о чем то другом?

← →
@!!ex © (2007-12-10 20:49) [107]

> [106] Palladin © (10.12.07 20:35)

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

P.S.
Пример, кстати, полностью попадает под спецификацию Паскаля, если я правильно помню.

← →
Palladin © (2007-12-10 20:52) [108]

> @!!ex © (10.12.07 20:49) [107]

без проблем... хоть я и попробовал пошарится по Object Pascal Reference для D6 на счет порядка вызовов в составных выражениях... безуспешно

как сказал мой друг: "когда дело касается правил языка, я смотрю в стандарт языка, а не в доки на компилятор"

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

Я конечно извиняюсь, но откланяюсь, домой нуна... продолжим завтра... а по поводу:

"Прикол с борландовским Си, когда выражение с сайд-эффектами давало разные результаты в зависимости от ключей компилятора -- притча во языцех"

исключение подтверждает правило...

Языки Pascal и Ada позволяют операндам бинарных выражений вычисляться в любом порядке, выбираемом разработчиком средств реализации языка.

Роберт У. Себеста, "Основные концепции языков программирования", 5-е изд.: Пер. с англ. - м.: "Издательский дом Вильямс", 2001
Раздел 6.2.2 "Порядок вычисления операндов", стр. 284

> Григорьев Антон © (10.12.07 20:58) [109]

пока жду машину

Антон, а что ты ожидаешь от
a:=f1(v)/f2(v)
где в обеих функциях параметр передается по ссылке и не заявлено и в документации компилятора вбсолютно вообще ничего не сказано об порядке исполнения вызовов? будешь ли ты делать так или же прибегнешь к:
tmp1:=f1(v);
tmp2:=f2(v);
a:=tmp1/tmp2;
?

>Mystic © (10.12.07 19:52) [99]
>Порядок выполнения операций определен, но где же порядок вычисления
>операндов?

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

> [0] Riply © (10.12.07 17:08)

Такой код писать иожно вообще умалишится, нахрена делать процедуру-функцию? Что-то одно выбрать нельзя.

> Palladin © (10.12.07 21:02) [110]
> Антон, а что ты ожидаешь от
> a:=f1(v)/f2(v)

Я и с делением экспериментировал. В простых ситуациях там тоже вторая функция вызывается раньше первой. Поэтому всегда, когда мне нужен гарантированный порядок вычисления операндов, я разношу эти вычисления по разным операторам.

> Сергей Суровцев © (10.12.07 21:14) [111]
> Порядок вычисления операндов может быть любым. Но вызов
> функции это еще не операнд.

Не понял этой фразы. Если операндом является функция, то чем вызов функции отличается от вычисления операнда?

>Palladin © (10.12.07 21:32) [112]
>кто сказал? (C) DimondShark

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

>Григорьев Антон © (10.12.07 21:38) [114]
>Не понял этой фразы. Если операндом является функция, то чем вызов
>функции отличается от вычисления операнда?

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

DiamondShark © (10.12.07 18:00) [45]
Единственно верный ответ.
Меня лично несколько удивило, что даже некоторые мастера что-то имеют против этого...

В большинстве языков не задаётся порядок вычисления ни операндов бинарной операции, ни аргументов функции. А потому использовать функции с side effect в таких ситуациях - зло. Хотя и известно, что Delphi выполняет всё слево напрово, но использовать это знание не рекомендуется, т.к. это не задокументировано и потому может измениться в любой момент. Например, если вдруг компилятор научится распараллеливать вычисление операндов, то результат такого выражения будет непредсказуемым. То, что скоро компиляторы так будут делать - я нисколько не сомневаюсь, потому что ядер скоро будет много, а распаралеллить такое вычисление не так уж и сложно.

> То, что скоро компиляторы так будут делать - я нисколько
> не сомневаюсь, потому что ядер скоро будет много, а распаралеллить
> такое вычисление не так уж и сложно.

В дополнение :

Суперскалярные процы уже потеряли предвыполнение ветки ветвления и переупорядочивание ? Ни в жисть не поверю. Уже почти нереально предсказать какой код выполниться раньше. Скорее всего обе функции поступят в конвейер одновременно. Но какая из них вернет результат первой, сильно заваисит от попадания данных в кэш.

tesseract © (10.12.07 22:14) [117]
Результат выполнения машинного кода должен быть один и тот же независимо от того, как процессор его выполняет. Так что какой бы он супер-пупер не был, семантика не должна меняться иначе не будет совместимости с предыдущими поколениями процессоров этого семейства, а она есть.
То есть в случае x86 всё зависит от компилятора, а нет от процессора.

> Palladin © (10.12.07 19:56) [101]
>
> а раз ничего подразумевать нельзя, то нельзя и работать
> с компилятором... так? мало ли чего он еще неподразумевает.
> .. или я не прав? вдруг он начнет компилировать задом наперед,
> бо быстрее будет... это ж не указано в документации...
> как он будет компилировать...

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

А про то, как интерпретировать описание, я уже говорил, только никто не слышал. Ну, мне повторить не сложно.
1. Следовать тому, что описано явно.
2. Что не описано явно, считать "зависимым от реализации".
Никто более разумной стратегии не предложил.

Кстати, интересно. Люди, посмотрите, кто может, как компилит выражения Дельфи для НЕТ.
Всё-таки, там стековая машина, значит кодогенератор будет отличаться от нативного х86.

Результат трехчасовых поисков ошибки в проекте :) Найти похожие ветки