Вычисление булевых выражений

← →
Anatoly Podgoretsky © (2006-11-30 13:17) [40]

> pasha_golub (30.11.2006 12:43:29) [29]

Включено, только ни о каких логических вычислениях и речи нет, вот пример, который ты обозвал трюком, как раз честный, идет логическое вычисление и слева и справа Boolean

← →
Anatoly Podgoretsky © (2006-11-30 13:19) [41]

> vuk (30.11.2006 12:47:31) [31]

Да посчитал и он имеет на это право, поскольку справа вариант, а там может быть и не Boolean

← →
Anatoly Podgoretsky © (2006-11-30 13:21) [42]

> Суслик (30.11.2006 12:50:32) [32]

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

Variant(1) and Variant2

Левую половину можно преобразовать в Вариант всегда, а правую в логическое не всегда.

← →
Anatoly Podgoretsky © (2006-11-30 13:22) [43]

> wal (30.11.2006 13:04:38) [38]

А еще лучше это в выглядит для True и еще лучше

Variant(False) и string

← →
TUser © (2006-11-30 13:30) [44]

Возможно отладчик глючит. Пару раз было, вроде. Лесился приемами типа
var i: integer;
begin
i := integer (YourPointer);
ShowMessage (inttostr (i));

конечно, не отладчик, но замена ему.

← →
wal © (2006-11-30 13:35) [45]

> [44] TUser © (30.11.06 13:30)
Да вроде разобрались уже, отладчик не причем

← →
Anatoly Podgoretsky © (2006-11-30 13:42) [46]

> TUser (30.11.2006 13:30:44) [44]

Да ничего не глючит, у него нормальный указатель, CPU это доказывает и правильно написаный код тоже работает, это тот где справа Expr = True

← →
Суслик © (2006-11-30 13:43) [47]

> [39] wal © (30.11.06 13:08)
>
> > [36] Суслик © (30.11.06 12:55)
> Это поведение описано в хелпе, какой же это баг?

Где описано? Какое конкретное слово? А?
Описано, что преобразует, но не описано, что вычисляет полностью.

← →
Суслик © (2006-11-30 13:51) [48]

> [39] wal © (30.11.06 13:08)
>
> > [36] Суслик © (30.11.06 12:55)
> Это поведение описано в хелпе, какой же это баг?

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

Ты где это нашел? Какой раздел?

PS. В BDS, кстати тоже самое.

← →
wal © (2006-11-30 14:00) [49]

> [48] Суслик © (30.11.06 13:51)
Ради тебя специально хелп перерыл, с тебя пиво.
Boolean operators
...
Note

If either operand involves a variant, the compiler always performs complete evaluation (even in the {$B-} state).

← →
Суслик © (2006-11-30 14:06) [50]

> [49] wal © (30.11.06 14:00)

Спасибо.
Это уже говорит о сабже!

Не знал, кстати.
Дя и вариантами не пользуюсь :)

(будешь в пятницу, будет пиво).

← →
Anatoly Podgoretsky © (2006-11-30 14:11) [51]

> wal (30.11.2006 14:00:49) [49]

Можно считать данный пост последней точкой

← →
wal © (2006-11-30 14:13) [52]

> [50] Суслик © (30.11.06 14:06)
> (будешь в пятницу, будет пиво).

Как-нибудь в следующий раз. На паравоз не успеваю.
Хотя мне и без этого насилия над хелпом еще из [19] стало понятно, что получаем мы Boolean(Variant(Param1) and Param2), что в данном случае and не является логической операцией, и, соответственно, short-circuit Boolean evaluation к ней неприменим.

← →
pasha_golub © (2006-11-30 14:57) [53]

> wal © (30.11.06 14:00) [49]

> Note
>
> If either operand involves a variant, the compiler always
> performs complete evaluation (even in the {$B-} state).

Спасибо. Хотя я бы это назвал не Note, a Warning. :)

← →
Суслик © (2006-11-30 15:29) [54]

> Хотя мне и без этого насилия над хелпом еще из [19] стало
> понятно, что получаем мы Boolean(Variant(Param1) and Param2),
> что в данном случае and не является логической операцией,
> и, соответственно, short-circuit Boolean evaluation к ней
> неприменим.

Какой гениальный :)
Вообще в коде

type o = class dd: string; function v: variant; end; function o.v; begin result := true; dd := "24123541"; end; procedure TForm1.Button1Click(Sender: TObject); var oo: o; begin oo := nil; if (oo <> nil) and oo.v then begin showmessage("a"); end; end;

Им ничего не мешало построить иной код

Unit1.pas.45: if (oo <> nil) and oo.v then

0046B6B9 8D45E4 lea eax,[ebp-$1c] 0046B6BC 837DF800 cmp dword ptr [ebp-$08],$00 0046B6C0 0F95C2 setnz dl 0046B6C3 E81899FAFF call @VarFromBool
например тут проверить, что результат @VarFromBool равен true.
0046B6C8 8D45E4 lea eax,[ebp-$1c] 0046B6CB 50 push eax 0046B6CC 8D55D4 lea edx,[ebp-$2c] 0046B6CF 8B45F8 mov eax,[ebp-$08] 0046B6D2 E879FFFFFF call o.v 0046B6D7 8D55D4 lea edx,[ebp-$2c] 0046B6DA 58 pop eax 0046B6DB E850B0FAFF call @VarAnd 0046B6E0 8D45E4 lea eax,[ebp-$1c] 0046B6E3 E88873FAFF call @VarToBool 0046B6E8 84C0 test al,al 0046B6EA 740A jz $0046b6f6

← →
Суслик © (2006-11-30 15:30) [55]

Топик все же очень полезный - век живи, иногда читай www.delphimaster.ru, век учись.

← →
wal © (2006-11-30 15:49) [56]

> например тут проверить, что результат @VarFromBool равен
> true.
И что? Сразу вернуть False? and в данном контексте не булева операция, и не обязана возвращать Variant(True) или Variant(False)

← →
Alx2 © (2006-11-30 15:58) [57]

>wal © (30.11.06 15:49)

А "if" разве не говорит о булевости?

← →
wal © (2006-11-30 16:02) [58]

> [57] Alx2 © (30.11.06 15:58)
Вот результат потом и приводится к Boolean, а сам оператор and разве "знает", что над ним if?

>wal © (30.11.06 16:02) [58]

> а сам оператор and разве "знает", что над ним if?

Это вроде как работа компилятора. Он же "знает", что применять если if a and b then ...
и если просто a := a and b;
побитовый and и логический как-то определены в синтаксисе. А здесь, мне кажется, выглядит как исключение из правил.

>wal © (30.11.06 16:02) [58]

Хотя неоднозначность есть - что-то вроде разницы между
if (a and b) и if (a) and (b) в случае вариантов

> [58] wal © (30.11.06 16:02)
>
> > [57] Alx2 © (30.11.06 15:58)
> Вот результат потом и приводится к Boolean, а сам оператор
> and разве "знает", что над ним if?

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

-------

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

> Это вроде как работа компилятора. Он же "знает" ...
Откуда? Он только на этапе проверки (в if) или присваивания (в :=) приводит результат к нужному типу.

Ладно, давай не спорить - все равно правды не найдем.
Я не согласен с такой семантикой. Ты, судя по всему, согласен.
Ну и ладно.

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

> [61] Суслик © (30.11.06 16:19)
> И что ты так защищаешь компилятор?
Да ничуть, просто разобрали конкретный пример, разобрали поведение компилятора, для себя я счел его правильным, к тому же, как выяснилось, это поведение документировано.

>Суслик © (30.11.06 16:19)

>И что ты так защищаешь компилятор?

Вовсе не защищаю.

>Это его дело - оптимизацией заниматься.

:)

>wal © (30.11.06 16:20) [62]

>Откуда? Он только на этапе проверки (в if)
>или присваивания (в :=) приводит результат к нужному типу.

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

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

Ну не надо :)
Ты сказал, что тебе было ясно это почти сразу. Ну я тебя гением обозвал. С этого то и началось. Хорошо - не гений.

Тут логика, со стороны разработчиков компилятора одна - так было сделать существенно проще. Почему? Не знаю. Но думаю, что это так.

Вычисление булевых выражений Найти похожие ветки