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

Немного Теории:
Логическое "И"
Рассмотрим простое утверждение: 1) "Мама и папа дома", однако по факту Мама пошла в магазин за хлебом. Это выражение правдиво?
Чуточку усложним: 2) "Мама, которая сейчас пошла в магазин за хлебом и папа находятся дома", Это выражение правдиво?
Переформулируем предложение: 3) "Папа дома и Мама, которая сейчас стоит в очереди в магазине, тоже дома". Это выражение тоже правдиво?

Конечно оба предложения ложны. Но почему то большинство программистов забывают об этих очевидных вещах!!! Ведь явно же видно что мама сейчас в магазине и смысла нет проверять, а дома ли папа? Вот и компилятор точно также, проверяет сначала одно под_условие, входящее в одно сложное условие и если оно ложно,то сколько бы не было под_условий после потом, он их рассматривать не будет! Т.к. уже известен результат!

Логическое "ИЛИ"
Берем опять 3) из Логическое "и". Если папа дома, то нет смысла проверять дальше, т.к. результат уже известен! Компилятор
видя конструкцию:

if (cond1) or (cond2) or (cond3) then

расссудит так: "Ха, раз cond1 истина, значит можно выполнять все что в then begin ... end; и наоборот. то что cond1 ложно, это еще значит, что cond2 тоже ложно!

Вывод:
Составляя большие условия, надо рассматривать а какое под условие наибольшую вероятность имеет быть в ложном или истинном состоянии? А какое чуточку меньше имеет вероятность быть в ложном или истинном? Зная эти особенности вы построете более эффективный код при выполнении. Почему?
Потому что:
1) Во первых быстрта проверки условия
2) Процессор имеет механизм предсказывания о том, какой код будет в дальнейшем. Следовательно правильно построенное условие, экономит процессору на его промахах!.

Нюансы:
Сам только сегодня открыл, хотелось бы предостеречь других от ошибки. Итак у меня код:
private:


Казалось бы корректный код,но! Я специально привел код именно в таком виде, т.к. код содержит не очевидную на первый взгляд особенность и в конечном итоге выливается в возможную багу при некоторых условиях.
Задаем вопрос: "А что если FPluginList не создан, что тогда?", ответ прост: "Будет бага!" и вот почему, в первом же под_условии смысл которого это проверка на кол-во элементов выполняется так, как будто бы FPluginList уже создан! А вдруг до применения этого метода FPluginList еще не создали? Логичней и правильней было бы вынести на первое место под_условие №2, в котором проверка на Nil.

Это код, можно чуточку с оптимизировать, поставив (Index >= 0) самым, первым, т.к. если мы передадим отрицательный индекс, то сразу же выйдем из метода тем самым сэкономим время на проверке трех других под_условиях. Хотя есть некоторые, зверюшки, которые сомневаются в целесообразности этого трюка ))

Это сообщение отредактировал(а) EvilsInterrupt - 8.10.2007, 06:10

Только учти, что если в Project -> Option -> Compiler будет отмечена галка "Complete Boolean Eval", то то что ты написал - не поможет... Выражение будет выполняться полностью, следовательно по прежнему будет бага... Избежать этого можно с помощью использования ключа компиляции {$B-} (поскольку ключ компиляции имеет более высокий приоритет, чем настройки проекта)

а я бы еще как минимум местами эти проверки поменял.
ибо если у тебя FPluginList=nil, то словишь AV при проверке первого условия

MetalFan, Уважаемый, читаем вниматильней, что я писал: 
,
 из этого следует что дальше идет пример кода! Подчеркну, пример кода! ;) Потом читаем: 
.

Из этих слов следует, что я знал о баге!!! Раз знал значит специально привел именно такой код! А почему? Да потому что: 


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

EvilsInterrupt, у тебя итоговая мысль, что надо вперед поверку на Index >= 0 вынести. что имхо логически некрасиво будет)


верно подметил)

MetalFan, я немного подправил, думаю сейчас поменьше сумбурности ;)

а вот я однажды наткнулся

а выведется тут

потому что если даже две переменные истина, то их равенство зависит от сравнения их как чисел.
т. е. 
и
это не одно и тоже

bems, раз уж ты делаешь прямое преобразование вместо того, чтобы написать

тогда уж объявляй переменные a и b как LongBool вместо Boolean.

я уже давно так не делаю. Как раз после того, как натолкнулся на такую тонкость


смотрим сюда

И что? Я же про переменные a и b.

почему?

Тогда то самое сравнение

будет давать корректный результат.

да. так и есть. туплю