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

Question

boolean a = false, b = true;
if ( a && b ) { ... };

В большинстве языков b не будет оцениваться, потому что a является ложным, поэтому a && b не может быть истинным. Мой вопрос: не будет ли короткое замыкание медленным с точки зрения архитектуры? В конвейере, вы просто зависаете в ожидании, чтобы получить результат a, чтобы определить, следует ли оценивать b или нет? Было бы лучше вместо этого делать вложенные ifs? Это даже помогает?

Кроме того, кто-нибудь знает, как обычно называется оценка короткого замыкания? Этот вопрос возник после того, как я узнал, что мой друг по программированию никогда не слышал об оценке короткого замыкания и заявил, что она не распространена, не встречается во многих языках и неэффективна в процессе разработки. Я не уверен насчет последнего, поэтому спрашиваю вас, ребята!

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

(a) if ( ( a != null ) && ( a.equals(b) ) ) { ... }

приведет к сбою системы, архитектура, которая не имеет короткого замыкания (и, следовательно, не допускает операторов, подобных приведенным выше), будет быстрее обрабатывать операторы, подобные этим:

(b) if ( ( a == 4 ) && ( b == 5 ) )

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

Я не знаю, правда это или нет.

Спасибо

Answer 1

Как можно вложить, если не заглохнуть? На самом деле, если a и b являются переменными, а не выражениями с побочными эффектами, они могут быть загружены параллельно хорошим компилятором. Нет смысла использовать больше ifs, кроме как увеличить количество строк. На самом деле, это было бы наихудшим вариантом угадывания компилятора.

Это называется оценкой короткого замыкания.

Answer 2

Один поток является последовательным, поэтому, если у вас есть два if, первое, конечно, будет оценено перед вторым, поэтому я не вижу разницы в этом. Я использую оператор условного AND (который && называется afaik) гораздо чаще, чем вложенный ifs. Если я хочу проверить что-то, что может занять некоторое время для оценки, сначала я делаю более простой тест, затем более сложный после условного и.

a = obj.somethingQuickToTest() && obj.somethingSlowToTest();

похоже не отличается от

<code>a = false;
if(obj.somethingQuickToTest())
   a = obj.somethingSlowToTest();

Answer 3

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

Answer 4

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

Answer 5

В зависимости от контекста его также можно назвать «охраной».

И я видел это почти на каждом языке, на котором я работал - что приближается к дюжине.