Почему язык НЕ использует оценку короткого замыкания? - PullRequest
Новая
       54

Почему язык НЕ использует оценку короткого замыкания?

38 голосов
/ 18 сентября 2009

Почему язык НЕ использует Оценка короткого замыкания ? Есть ли польза от его использования?

Я вижу, что это может привести к проблемам с выступлениями ... это правда? Почему?

Соответствующий вопрос: Преимущества использования оценки короткого замыкания

Ответы [ 18 ]

2 голосов
/ 18 сентября 2009

Язык программирования Ada поддерживает оба логических оператора, которые не замыкаются накоротко (AND, OR), чтобы позволить компилятору оптимизировать и, возможно, распараллеливать конструкции, и операторы с явным запросом короткое замыкание (AND THEN, OR ELSE), когда этого желает программист. Недостаток такого двойного подхода - сделать язык немного более сложным (1000 проектных решений, принятых в одной и той же схеме «давайте сделаем оба!», Сделают язык программирования в целом более сложным; -).

1 голос
/ 18 сентября 2009

Поскольку короткое замыкание может изменить поведение приложения IE: 

if(!SomeMethodThatChangesState() || !SomeOtherMethodThatChangesState())
1 голос
/ 18 сентября 2009

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

Если память служит, erlang предоставляет две конструкции, стандартную и / или, затем andalso / orelse. Это уточняет намерение, что «да, я знаю, что это короткое замыкание, и вы тоже должны», где, как и в других точках, намерение должно быть получено из кода.

Например, скажем, сопровождающий встречает следующие строки: 

if(user.inDatabase() || user.insertInDatabase()) 
    user.DoCoolStuff();

Требуется несколько секунд, чтобы понять, что намерение таково: «если пользователь отсутствует в базе данных, вставьте его / ее / ее; если это работает, делайте классные вещи».

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

0 голосов
/ 18 сентября 2009

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

Это всего лишь одна из вещей, из-за которой мне было очень трудно перестать быть программистом VB Noob, который писал код для спагетти, и продолжить свое путешествие, чтобы стать настоящим программистом. 1005 *

0 голосов
/ 18 сентября 2009

Оценка короткого замыкания автоматически обеспечивает условную оценку части выражения.

Главное преимущество в том, что оно упрощает выражение.

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

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

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

0 голосов
/ 18 сентября 2009

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

0 голосов
/ 24 февраля 2012

Многие ответы говорили о побочных эффектах. Вот пример Python без побочных эффектов, в котором (на мой взгляд) короткое замыкание улучшает читабельность. 

for i in range(len(myarray)):
  if myarray[i]>5 or (i>0 and myarray[i-1]>5):
    print "At index",i,"either arr[i] or arr[i-1] is big"

Короткое замыкание гарантирует, что мы не попытаемся получить доступ к myarray [-1], что вызовет исключение, поскольку массивы Python начинаются с 0. Код, конечно, может быть написан без коротких замыканий, например, 

for i in range(len(myarray)):
  if myarray[i]<=5: continue
  if i==0: continue
  if myarray[i-1]<=5: continue
  print "At index",i,...

но я думаю, что версия с коротким замыканием более читаема.

0 голосов
/ 18 сентября 2009

Уже есть хорошие отзывы о проблеме с побочными эффектами, но я ничего не видел в аспекте производительности вопроса.

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

  • Код находится во внутреннем цикле, который очень часто вызывается
  • Существует высокая стоимость, связанная с оценкой выражений (возможно, IO или дорогостоящее вычисление)
Страница:
...