Проблемы с Uint64

Общие вопросы программирования, алгоритмы и т.п.

Модератор: Модераторы

Re: Проблемы с Uint64

Сообщение Лекс Айрин » 17.08.2016 13:07:27

alexey38, при обычном коммерческом проекте, тоже не погладят по голове. Бывает, что и весь проект закрывают, а программистов увольняют.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: Проблемы с Uint64

Сообщение Снег Север » 17.08.2016 13:09:11

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

+100500
"неча на зеркало пенять, коли рожа крива!"
Аватара пользователя
Снег Север
долгожитель
 
Сообщения: 2993
Зарегистрирован: 27.11.2007 16:14:47

Re: Проблемы с Uint64

Сообщение azsx » 17.08.2016 17:17:28

скажите, пожалуйста, так a>b это надо было первым условием проверить? А уже потом минусовать? То есть:
Код: Выделить всё
if (a > b) AND (a - b > c) then

верно?
azsx
энтузиаст
 
Сообщения: 959
Зарегистрирован: 16.11.2015 06:38:32

Re: Проблемы с Uint64

Сообщение zub » 17.08.2016 17:32:59

Если нет возможности уйти от беззнаковых типов - придется сравнивать.
И даже со знаковыми типами возможность переполнения всеравно надо учитывать
zub
долгожитель
 
Сообщения: 2884
Зарегистрирован: 14.11.2005 23:51:26

Re: Проблемы с Uint64

Сообщение alexey38 » 18.08.2016 09:30:03

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


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

Добавлено спустя 6 минут 52 секунды:
azsx писал(а):скажите, пожалуйста, так a>b это надо было первым условием проверить? А уже потом минусовать? То есть:
Код: Выделить всё
if (a > b) AND (a - b > c) then

верно?


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

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

Re: Проблемы с Uint64

Сообщение Дож » 19.08.2016 14:38:28

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

Мы именно что знаем, сперва будет выполнено первое сравнение, а второе будет выполнено только если первое оказалось истинным. Указанная директива $B есть и в fpc и она, как и полагается уважающему себя современному ЯП, включена по умолчанию.
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

Re: Проблемы с Uint64

Сообщение alexey38 » 22.08.2016 09:22:08

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

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


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

Другое дело, что, например, 2007 версия Дельфей даже при включенном "Overflow checking" не формирует исключения для типа Word, но сформирует для LongWord и UInt64, если переполнение было внутри условий. Это как раз и есть особенность реализации, которая может быть разной.
alexey38
долгожитель
 
Сообщения: 1627
Зарегистрирован: 27.04.2011 19:42:31

Re: Проблемы с Uint64

Сообщение Лекс Айрин » 22.08.2016 09:50:21

alexey38, в любом случае, стоит избегать подобного непотребства.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: Проблемы с Uint64

Сообщение Дож » 22.08.2016 14:02:28

alexey38, я ошибся в описании поведения $B+, а в том, что происходит по дефолту — нет, повсеместно используются конструкции вида
Код: Выделить всё
if (P <> nil) and P^.IsStatus then
  ...


Неленивыми логические операторы в паскале были, наверное, в восьмидисятые.
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

Re: Проблемы с Uint64

Сообщение alexey38 » 22.08.2016 20:55:02

Дож писал(а):alexey38, я ошибся в описании поведения $B+, а в том, что происходит по дефолту — нет, повсеместно используются конструкции вида
Код: Выделить всё
if (P <> nil) and P^.IsStatus then
  ...

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


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

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

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

Ленивые логические операции вроде бы как в Си идут стандартом.
alexey38
долгожитель
 
Сообщения: 1627
Зарегистрирован: 27.04.2011 19:42:31

Re: Проблемы с Uint64

Сообщение Лекс Айрин » 22.08.2016 21:01:59

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


Если бы только в Си... наверняка они еще в фортране были... и назывались приоритет операций (который бывает не только вертикальный, но и горизонтальный).
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 5723
Зарегистрирован: 19.02.2013 16:54:51
Откуда: Волгоград

Re: Проблемы с Uint64

Сообщение Дож » 23.08.2016 11:40:04

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

Так а может там требуют код не только не чувствительный к опциям, но и к компилятору? Вдруг для компиляции будут использовать не fpc, а какой-нибудь petropascal, это должен учитывать промышленный автоматизатор?
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

Re: Проблемы с Uint64

Сообщение zub » 23.08.2016 13:58:05

alexey38
Ты прям жути нагоняешь)) ошибки не приветствуются нигде. Там где нужна надежность - должны быть соответствующие инструменты.
Не думаю что fpc где то серьезно используется в этой отрасли
zub
долгожитель
 
Сообщения: 2884
Зарегистрирован: 14.11.2005 23:51:26

Re: Проблемы с Uint64

Сообщение Mikhail » 23.08.2016 16:25:17

Дож писал(а):alexey38, я ошибся в описании поведения $B+, а в том, что происходит по дефолту — нет, повсеместно используются конструкции вида
Код: Выделить всё
if (P <> nil) and P^.IsStatus then
  ...


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

ИМХО, такой код является безграмотным.
Mikhail
энтузиаст
 
Сообщения: 562
Зарегистрирован: 24.10.2013 16:06:47

Re: Проблемы с Uint64

Сообщение Дож » 23.08.2016 16:33:20

ИМХО человека, искренне считающего, что в программах на Java не бывает утечек памяти :)
Аватара пользователя
Дож
энтузиаст
 
Сообщения: 899
Зарегистрирован: 12.10.2008 16:14:47

Пред.

Вернуться в Общее

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13

Рейтинг@Mail.ru