softwarerresult := not Assigned ( requirement ) or requirement ;[/src]
Жестоко людям советовать код, работоспособность которого зависит от настроек компилятора.

softwarer LordMADЖестоко людям советовать код, работоспособность которого зависит от настроек компилятора.
Фраза формально верна, но с ее сутью я в данном случае не соглашусь. Сами по себе подобные настройки - огромное зло и головотяпство. Это относится и к ряду дельфовых переключателей, и ко многим другим продуктам. Наличие такой настройки фактически означает отсутствие у идеологов продукта.... затруднюсь подобрать подходящее слово, есть такая идиома - "политическая воля", так вот, отсутствие "неполитической политической воли".

Дык вот, с моей точки зрения, все - даже не "все нормальные люди", а "практически все" - по факту давным-давно согласны о том, какие значения этих настроек "стандартны", и если вдруг где-то по каким-то соображениям решают от них отступить - знают об этом, пишут пять предупреждений вокруг итп. Если сегодня найдется человек, у которого стоит {$B+} или, допустим, {$H-}, и он об этом не помнит и не знает - это исключительно его проблема, можно вполне смело утверждать, что практически любой чужой код заметной длины - включая нестандартные компоненты (и стандартные, кстати, тоже) у него корректно не заработает.
Дело в другом, можно просто ошибочно после какого-то куска кода, в котором {$B+}, забыть его отменить {$B-}, ведь бывают случаи, когда в результате анализа производительности кода имеет смысл поставить {$B+}.

softwarerВ первую очередь, я не вижу практического смысла в наличии таких ключей в коде вообще.Я уже привел пример - это увеличение производительности.
softwarerНо в любом случае обоснование довольно странное - этак можно и сказать, мол, "перед посоветованным кодом я поставил begin, а после - забыл поставить end, так вот, он почему-то не работает".Я бы согласился, если бы отсутствие выключения ключа приводило бы к ошибке/предупреждению/хинту на этапе компиляции.

softwarer LordMADЯ уже привел пример - это увеличение производительности.
Я помню и отвечаю с учетом этого.Ты не видишь практического смысла в увеличении производительности с помошью таких ключей?

softwarerСкажу так: с моей точки зрения, требование писать код так, чтобы он корректно работал при любых настройках Syntax Options - издевательство над программистом. Наверное, жестким регламентом такого добиться, но это на редкость непрактично.А советовать код, который работает только при определенных настройках, но не упомянуть об этих настройках, это не издевательство? ;)

softwarerЯ не вижу смысла писать на дельфе фрагменты кода, из которого потребуется выжимать производительность таким образом. Лучше использовать ассемблерные вставки и/или более оптимизирующий компилятор.Во-первых, ты слишком плохого мнения об этом компиляторе - помогая ему разными такими безделушками, можно получить довольно неплохих результатов (с учетом того, что код при этом остается хорошо читаем). Во-вторых, если говорить о delphi language, то более оптимизирующего компилятора не видать :(. В-третьих, нужно все-таки соизмерять трудозатраты по оптимизации - писать кусок на ассемблере - это зачастую в наше время через чур: несколько лишних mov, которые сделает копилятор - погоды уже не делают, а вот избавится от неоправданных условных переходов можно иногда и с помошью {B+}.