short-circuiting

I tried something along the lines of: if(myString != nil && myString.length) { ... } And got: -[NSNull length]: unrecognized selector sent to instance Does Objective-C not short-circuit after the first condition fails? Objective-C does support short-circuit evaluation, just like C. It seems that in your example myString is NSNull and not nil , therefore myString != nil is true. NSNull is a singleton and is used to represent nil where only objects are allowed, for example in an NSArray. Btw, normally, people write if (!myString && myString.length == 0) . Comparing to nil is quite ugly. Also, I

If I write two SELECT statements in a IF EXISTS condition with a AND clause in between these select queries, does both queries get executed even if the first SELECT returns false? IF EXISTS (SELECT....) AND EXISTS(SELECT ....) BEGIN END Does the SQL Server Engine execute both the SQL Statement in this scenario? Thanks Krish I would rewrite the test as IF CASE WHEN EXISTS (SELECT ...) THEN CASE WHEN EXISTS (SELECT ...) THEN 1 END END = 1 This guarantees short circuiting as described here but does mean you need to select the cheapest one to evaluate up front rather than leaving it up to the

The short circuiting behaviour of the operators && and || is an amazing tool for programmers. But why do they lose this behaviour when overloaded? I understand that operators are merely syntactic sugar for functions but the operators for bool have this behaviour, why should it be restricted to this single type? Is there any technical reasoning behind this? Eric Lippert All design processes result in compromises between mutually incompatible goals. Unfortunately, the design process for the overloaded && operator in C++ produced a confusing end result: that the very feature you want from && --

What construct should I use to check whether a value is NULL in a Twig template? Depending on what exactly you need: is null checks whether the value is null : {% if var is null %} {# do something #} {% endif %} is defined checks whether the variable is defined: {% if var is not defined %} {# do something #} {% endif %} Additionally the is sameas test, which does a type strict comparison of two values, might be of interest for checking values other than null (like false ): {% if var is sameas(false) %} {# do something %} {% endif %} lax4mike How to set default values in twig: http://twig

I know that || and && are defined as short-circuit operators in C#, and such behaviour is guaranteed by the language specification, but do |= and &= short-circuit too? For example: private bool IsEven(int n) { return n % 2 == 0; } private void Main() { var numbers = new int[] { 2, 4, 6, 8, 9, 10, 14, 16, 17, 18, 20 }; bool allEven = true; bool anyOdd = false; for (int i = 0; i < numbers.Length; i++) { allEven &= IsEven(numbers[i]); anyOdd |= !IsEven(numbers[i]); } } When the 9 entry is hit, allEven becomes false, meaning that all subsequent entries are irrelevant - the value of allEven is

I can't find the relevant portion of the spec to answer this. In a conditional operator statement in Java, are both the true and false arguments evaluated? So could the following throw a NullPointerException Integer test = null; test != null ? test.intValue() : 0; Michael Myers Since you wanted the spec, here it is (from §15.25 Conditional Operator ? : , the last sentence of the section): The operand expression not chosen is not evaluated for that particular evaluation of the conditional expression. Michał Króliczek I know it is old post, but look at very similar case and then vote me :P

This question already has an answer here: AndAlso/OrElse in VBA 7 answers VBA doesn't short-circuit VBA does not support short-circuiting - apparently because it only has bitwise And/Or/Not etc operations. From the VBA language specification : "Logical operators are simple data operators that perform bitwise computations on their operands." In this light, it makes sense that VBA was designed with true = &H1111 and false = &H0000 : this way logical statements can be evaluated as bitwise operations. The lack of short-circuiting can cause problems Performance: the ReallyExpensiveFunction() will