Когда плохая оценка короткого замыкания?

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

Теперь я начинаю работу над проектами, требующими VB.net, и я вижу, что он предоставляет оба способа с точки зрения AND и ANDALSO . Первый не закорачивает, а второй делает.

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

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

Хотя я надеюсь, что, по крайней мере, есть официальный ответ о том, почему было бы лучше иметь оба варианта, чем всегда делать короткое замыкание , когда оно доступно.

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

if not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

В других случаях вы не хотите оценивать какие-либо из оставшихся терминов, если более ранняя оценка возвращает false.

if IsAirborne() and not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

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

VAL's ANDALSO является четким и, кажется, попыткой сделать практику более приемлемой.

Как указывает JimmyJames в своем ответе, при оценке короткого замыкания могут быть ощутимые последствия для производительности. Языки, которые не предоставляют механизм, всегда оценивают каждый термин выражения, в то время как те, которые предоставляют его, могут генерировать дополнительные операторы ветвления. В любом случае, многое зависит от количества этапов обработки, необходимых для оценки каждого из терминов, а также от архитектуры компилятора и процессора. Обычно вы не заботитесь о таких вещах до тех пор, пока у вас не возникнет серьезное узкое место в коде, и вам не придется решать, как его устранить. Любые правила «делать или не делать», касающиеся разрешения оценки короткого замыкания в вашем коде, будут иметь примерно равную вероятность вызвать более медленный код, а ранняя оптимизация может быть пустой тратой времени, поэтому всегда измеряйте, а затем оптимизируйте.

По-видимому, ваш вопрос не в том, является ли короткое замыкание хорошим или плохим в целом, а в том, почему VB.NET предоставляет операторам и без него. Имея это в виду, ответ на

когда плохая оценка короткого замыкания?

это просто: когда это нарушает обратную совместимость .

Хорошо, теперь вы можете сказать, что VB.NET не очень обратно совместим со старым VB6 или VBA, однако, по крайней мере, некоторые части языка таковы. Решение Microsoft о сохранении старой семантики «И» и «ИЛИ» (без короткого замыкания) сделало огромную категорию ошибок менее вероятной при переносе старых программ VB в VB.NET.

С другой стороны, дизайнеры языка VB.NET, вероятно, поделились своим мнением о том, что короткое замыкание - это хорошо. Когда я правильно помню, первые предварительные версии VB.NET предоставляли операторам И или ИЛИ короткое замыкание, но отзывы разработчиков, должно быть, были настолько плохими, что MS отозвала это решение до появления VB.NET 1.0. Поэтому дизайнеры решили реализовать его с точки зрения новых ключевых слов ANDALSOи ORELSEкак компромисс между обратной совместимостью и полезностью.

ИМХО это было хорошее решение. Мне пришлось портировать несколько старых программ за последнее десятилетие, и не нужно было проводить тяжелый анализ воздействия для каждого логического выражения, включая AND и / или OR (каламбур), что значительно облегчило эту задачу и стало более экономичным. С другой стороны, всякий раз, когда мне нужно написать новое логическое выражение в VB.NET, мой выбор по умолчанию для операторов - это формы короткого замыкания, к которым я привык из C, C ++, C # и т. Д., И это позволяет мне написать несколько идиом в более сжатой форме (даже если ANDALSO нужно еще 4 символа для ввода).

Если вы не уверены, я рекомендую прочитать замечательную статью Джоэла Спольски о марсианских гарнитурах , из-за которой ранние проектные решения в разработке программного обеспечения не могут быть легко отменены после того, как рассматриваемый компонент, язык или API достигли базы пользователей определенного размера. ,

когда плохая оценка плохого?

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

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

Причина, по которой это редко имеет значение, заключается в том, что стоимость, как правило, невелика, а также обычно перевешивается стоимостью оценки второго (или третьего и т. Д.) Условия. Это когда-либо будет иметь значение только в вычислительно дорогих подпрограммах, когда требуется высокая производительность, и это может все еще не иметь значения тогда.

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

C и C ++ имеют побитовые операции & и | которые на практике дают вам операции без короткого замыкания. И компиляторы могут свободно оценивать их так, как им нравится, если это не имеет заметного значения.