freepascal.ru

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

alexey38 писал(а):Поэтому алгоритм программы должен быть составлен таким образом, чтобы были полностью исключены неопределенности компиляторов и т.п.

+100500
"неча на зеркало пенять, коли рожа крива!"

скажите, пожалуйста, так a>b это надо было первым условием проверить? А уже потом минусовать? То есть:

верно?

Если нет возможности уйти от беззнаковых типов - придется сравнивать.
И даже со знаковыми типами возможность переполнения всеравно надо учитывать

Лекс Айрин писал(а):alexey38, при обычном коммерческом проекте, тоже не погладят по голове. Бывает, что и весь проект закрывают, а программистов увольняют.

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

Добавлено спустя 6 минут 52 секунды:

azsx писал(а):скажите, пожалуйста, так a>b это надо было первым условием проверить? А уже потом минусовать? То есть:

Код: Выделить всё

if (a > b) AND (a - b > c) then 

верно?

В общем случае мы не знаем, в каком порядке компилятор (а они со временем могут быть разными, в т.ч. в зависимости от опций) будет выполнять арифметические действия и сравнения внутри одного оператора. Поэтому более правильным является разбитие этого условия на два, вместо "AND".

Например, в Delphi есть опция "Complete boolean eval" (директива {$B}). То есть вычисление всех элементов булева выражения, даже если результат выражения очевиден после вычисления первых элементов (например, в операции И вычисляются оба операнда, даже если первый из них равен false).

В общем случае мы не знаем, в каком порядке компилятор (а они со временем могут быть разными, в т.ч. в зависимости от опций) будет выполнять арифметические действия и сравнения внутри одного оператора. Поэтому более правильным является разбитие этого условия на два, вместо "AND".

Мы именно что знаем, сперва будет выполнено первое сравнение, а второе будет выполнено только если первое оказалось истинным. Указанная директива $B есть и в fpc и она, как и полагается уважающему себя современному ЯП, включена по умолчанию.

Дож писал(а):

В общем случае мы не знаем, в каком порядке компилятор (а они со временем могут быть разными, в т.ч. в зависимости от опций) будет выполнять арифметические действия и сравнения внутри одного оператора. Поэтому более правильным является разбитие этого условия на два, вместо "AND".

Мы именно что знаем, сперва будет выполнено первое сравнение, а второе будет выполнено только если первое оказалось истинным. Указанная директива $B есть и в fpc и она, как и полагается уважающему себя современному ЯП, включена по умолчанию.

Вы ошибаетесь. По крайней мере для Дельфи Вы описали оптимизированный алгоритм работы при снятой опции "$B-". При включенной опции "$B+" произойдет выполнение всех операций, внутри "if" вне зависимости от того успешно ли было выполнено первое условие или нет. В этом и заключается смысл опции "$B".

Другое дело, что, например, 2007 версия Дельфей даже при включенном "Overflow checking" не формирует исключения для типа Word, но сформирует для LongWord и UInt64, если переполнение было внутри условий. Это как раз и есть особенность реализации, которая может быть разной.

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

alexey38, я ошибся в описании поведения $B+, а в том, что происходит по дефолту — нет, повсеместно используются конструкции вида


Неленивыми логические операторы в паскале были, наверное, в восьмидисятые.

Дож писал(а):alexey38, я ошибся в описании поведения $B+, а в том, что происходит по дефолту — нет, повсеместно используются конструкции вида

Код: Выделить всё

if (P <> nil) and P^.IsStatus then
  ...

Неленивыми логические операторы в паскале были, наверное, в восьмидисятые.

Вот указанный Вами код при включенной опции "$B+" создаст исключение. Потому, что опция "$B" как раз и управляет будут ли ленивыми или не ленивыми логические операции.

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

Соответственно у нас было нельзя писать как такой код, когда может возникать исключение, так и нельзя было писать код рассчитанный именно на "неленивость" ("$B+"), когда из условий вызывались функции с глобальными последствиями (их вызов или не вызов влияет на работу алгоритма). Карали за такое строго, как и за другие виды неявного кода с побочными эффектами.

Ленивые логические операции вроде бы как в Си идут стандартом.

alexey38 писал(а):Ленивые логические операции вроде бы как в Си идут стандартом.

Если бы только в Си... наверняка они еще в фортране были... и назывались приоритет операций (который бывает не только вертикальный, но и горизонтальный).

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

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

alexey38
Ты прям жути нагоняешь)) ошибки не приветствуются нигде. Там где нужна надежность - должны быть соответствующие инструменты.
Не думаю что fpc где то серьезно используется в этой отрасли

Дож писал(а):alexey38, я ошибся в описании поведения $B+, а в том, что происходит по дефолту — нет, повсеместно используются конструкции вида

Код: Выделить всё

if (P <> nil) and P^.IsStatus then
  ...

Неленивыми логические операторы в паскале были, наверное, в восьмидисятые.

ИМХО, такой код является безграмотным.

ИМХО человека, искренне считающего, что в программах на Java не бывает утечек памяти :)