Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

дерективы компилятора [D7, XP]

Страницы: 1 2 >
malyar © (2007-08-31 11:57:00)
всем привет
народ подскажите дерективу компилятора которая прервет цепь проверок при первом false, как она активируется и деактивируется ?

if (a=1) and(s>100) and(d=0) then......

Anatoly Podgoretsky (2007-08-31 13:49:00) [1]
А если это важно, то и писать стоит соответственно
if a=1 then begin
if s>100 then begin
if d=0 then begin
...
end;
end;
end;
И неприятностей от флагов ожидать не надо.
И в отладке удобно, можно поставить точки останова где нужно.

Kolan (2007-08-31 13:38:00) [2]
Сохранил ветку :)

Юрий Зотов (2007-08-31 13:36:00) [3]
> Kolan © (31.08.07 13:26) [24]

Из серии "маленькие хитрости от дяди Юры": у меня заготовлены inc-файлы с подобными обертками.Там, где надо, я просто ставлю $I с нужным файлом, это сокращает количество писанины.

:o)

Kolan (2007-08-31 13:34:00) [4]
Блин, буду знать теперь…

Юрий Зотов (2007-08-31 13:32:00) [5]
> Kolan © (31.08.07 13:26) [24]

Главное - чтобы код был надежным. Каким способом это сделано - неважно.

homm (2007-08-31 13:30:00) [6]
> [21] Kolan © (31.08.07 13:19)
> А где иначе?

Где угодно. Разницу в словах «стандартная» и «по умолчанию» чувствуешь?

Kolan (2007-08-31 13:26:00) [7]
> Если проект может компилировать кто-то еще кроме Вас, то
> обязательно.

Может проще тогда сделать два if'а ?

Юрий Зотов (2007-08-31 13:23:00) [8]
> Kolan © (31.08.07 13:19) [20]
> их все надо обернуть подобной оберткой?

Если проект может компилировать кто-то еще кроме Вас, то обязательно.
Если нет - то желательно.

Инс (2007-08-31 13:21:00) [9]

> А где иначе?

Насколько мне известно, такое поведение стандартно только для паскаля. Возможно ошибаюсь, поправьте.

Kolan (2007-08-31 13:19:00) [10]

> Чьи проблемы?

А где иначе?

Kolan (2007-08-31 13:19:00) [11]
> [15] Юрий Зотов © (31.08.07 13:08)
> > Инс
>
> С учетом того, что условие может быть включено/выключено
> в опциях проекта:

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

homm (2007-08-31 13:18:00) [12]
> [16] Kolan © (31.08.07 13:08)
> Непонятно зачем надо собатировать(с пом. ключа) нормальную
> логику проверок.
Саботировать? Критерий нормальности где?

> [16] Kolan © (31.08.07 13:08)
> Я считал её стандартной…
Чьи проблемы?

Инс (2007-08-31 13:15:00) [13]

> В данном случае, с директивой {$B-} будет происходить AV
> в случае, если GetUserName = nil.

Правда наоборот, с директивой $B+ будет AV

> [15] Юрий Зотов © (31.08.07 13:08)

Ага. Именно так.

Leonid Troyanovsky (2007-08-31 13:12:00) [14]

> Kolan © (31.08.07 13:08) [16]

> Непонятно зачем надо собатировать(с пом. ключа) нормальную
> логику проверок. Я считал её стандартной…

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

--
Regards, LVT.

Kolan (2007-08-31 13:08:00) [15]
> Сравнивают не всегда переменные, а иногда и результаты функций,
>

Понятное дело.

> В данном случае, с директивой {$B-} будет происходить AV
> в случае, если GetUserName = nil.

Понятно что в подобых случаях будет ошибка.

Непонятно зачем надо собатировать(с пом. ключа) нормальную логику проверок. Я считал её стандартной…

Юрий Зотов (2007-08-31 13:08:00) [16]
> Инс

С учетом того, что условие может быть включено/выключено в опциях проекта:
{$IFDEF B+} {$DEFINE BPlus} {$ENDIF} {$B-} ... // Критичный код {$IFDEF BPlus} {$UNDEF BPlus} {$B+} {$ENDIF}

Инс (2007-08-31 13:04:00) [17]
Дабы не быть голословным, вот пример из моего проекта, где это необходимо:
// Получаем имя пользователя @GetUserName := GetProcAddress(prov,'kpGetUserName'); if (not Assigned(GetUserName)) or (not GetUserName(nil,unLen)) then Error(rsUserName);

В данном случае, с директивой {$B-} будет происходить AV в случае, если GetUserName = nil.

Инс (2007-08-31 12:58:00) [18]

> Сравнивают не всегда переменные, а иногда и результаты функций

Именно.

Инс (2007-08-31 12:57:00) [19]

> Интересно кому може вообще поннадобится отключать это…

Такому же программисту как я, для которого поведение {$B-} либо привычнее, либо принципиально, так как иначе будет работать неверно. На подобных авось, уважаемый, надежный код не построишь. И воздержись от наездов, ты сейчас объективно неправ.

homm (2007-08-31 12:57:00) [20]
> [10] Kolan © (31.08.07 12:53)

Ты не прав ©

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »