short-circuiting

Java logical operator (&&, ||) short-circuit mechanism

最后都变了- 提交于 2019-12-05 12:13:52
问题 As I was reading a colleague's Java code, I stumbled upon an army of if/else statements. In these statements, several && and || operators were fighting each other without any help from parenthesis. I simplified the statements into: if (true || true && false) return true; else return false; What do you think the result would be? Honestly, I thought it would be false , but it seems short-circuiting doesn't work like I expected. In this case, the result is true . The short-circuit mechanism

Shortcircuiting: OrElse combined with Or

微笑、不失礼 提交于 2019-12-05 08:40:39
If I have the following ... a OrElse b ... and a is True then clearly b is never evaluated. But if I add an Or , then what? a OrElse b Or c Does/should c get evaluated? And what if I put in some brackets? Apologies if this is basic. Of course I can test for the answer myself but I can't find this question answered here or elsewhere. Lots of questions dealing with Or versus OrElse but nothing dealing with Or with OrElse This is an operator precedence problem. The relevant documentation is here: http://msdn.microsoft.com/en-us/library/fw84t893.aspx?ppud=4 The important excerpts: Operators with

Verify that an OCaml function is tail-recursive

巧了我就是萌 提交于 2019-12-05 05:50:08
How can I tell if OCaml recognizes a particular function as tail-recursive? In particular, I want to find out if the OCaml compiler recognizes Short-circuited operators and tail recursion Thanks to Jeffrey's answer below, I tried this with the simple function let rec check_all l = match l with | [] -> true | hd :: tl -> hd && check_all tl and indeed, it does optimize to: camlTest__check_all_1008: .cfi_startproc .L102: cmpl $1, %eax je .L100 movl (%eax), %ebx cmpl $1, %ebx je .L101 movl 4(%eax), %eax jmp .L102 .align 16 .L101: movl $1, %eax ret Starting from OCaml 4.03, and despite the typo in

How to do parallel “either-side” short-circuiting with “and” and “or”

本秂侑毒 提交于 2019-12-05 01:37:01
Does haskell have a parallel "and" method parAnd :: Bool -> Bool -> Bool such that (a `parAnd` b) will spark the evaluation of a and b in parallel and return false as soon as either a or b evaluates to false (and not wait for the other one)? Is there some way to implement such a thing? Normally, this is not possible. You can do something like a `par` b `pseq` (a && b) but if b evaluates to False , a is still fully evaluated. However, this is possible with the unambiguous choice operator created by Conal Elliott for his Functional Reactive Programming (FRP) implementation. It's available on

Is there anything like “std::and” or “std::or”?

自作多情 提交于 2019-12-04 22:26:19
Given a container of boolean values (An example is std::vector<bool> ), is there a standard function that returns true if all the values are true ("and") or true if at least one value is true ("or"), with short circuit evalutation ? I digged trough www.cplusplus.com this morning but couldn't find anything close. You can implement by: AND: std::find(vector.begin(), vector.end(), false) == vector.end() // all the values are true OR: std::find(vector.begin(), vector.end(), true) != vector.end() //at least one value is true is there a standard function that returns true if all the values are true

Does c# ?? operator short circuit?

て烟熏妆下的殇ゞ 提交于 2019-12-04 22:16:06
When using the ?? operator in C#, does it short circuit if the value being tested is not null? Example: string test = null; string test2 = test ?? "Default"; string test3 = test2 ?? test.ToLower(); Does the test3 line succeed or throw a null reference exception? So another way to phrase the question: Will the right hand expression of the ?? operator get evaluated if the left hand is not null? Yes, it says so in the C# Language Specification (highlighting by me): A null coalescing expression of the form a ?? b requires a to be of a nullable type or reference type. If a is non-null, the result

I don't like this… Is this cheating the language?

六眼飞鱼酱① 提交于 2019-12-04 18:12:51
问题 I have seen something like the following a couple times... and I hate it. Is this basically 'cheating' the language? Or.. would you consider this to be 'ok' because the IsNullOrEmpty is evaluated first, all the time? (We could argue whether or not a string should be NULL when it comes out of a function, but that isn't really the question.) string someString; someString = MagicFunction(); if (!string.IsNullOrEmpty(someString) && someString.Length > 3) { // normal string, do whatever } else { /

Calling methods inside if() - C#

百般思念 提交于 2019-12-04 18:09:00
问题 I have a couple of methods that return a bool depending on their success, is there anything wrong with calling those methods inside of the IF() ? //&& makes sure that Method2() will only get called if Method1() returned true, use & to call both methods if(Method1() && Method2()) { // do stuff if both methods returned TRUE } Method2() doesn't need to fire if Method1() returns FALSE. Let me know there's any problem with the code above. thank you. EDIT: since there was nothing wrong with the

Do short-circuiting operators || and && exist for nullable booleans? The RuntimeBinder sometimes thinks so

孤街醉人 提交于 2019-12-04 07:29:40
问题 I read the C# Language Specification on the Conditional logical operators || and && , also known as the short-circuiting logical operators. To me it seemed unclear if these existed for nullable booleans, i.e. the operand type Nullable<bool> (also written bool? ), so I tried it with non-dynamic typing: bool a = true; bool? b = null; bool? xxxx = b || a; // compile-time error, || can't be applied to these types That seemed to settle the question (I could not understand the specification clearly

Why do logical operators in C not evaluate the entire expression when it's not necessary to?

痴心易碎 提交于 2019-12-04 04:03:34
问题 I was reading my textbook for my computer architecture class and I came across this statement. A second important distinction between the logical operators ' && ' and ' || ' versus their bit-level counterparts ' & ' and ' | ' is that the logical operators do not evaluate their second argument if the result of the expression can be determined by evaluating the first argument. Thus, for example, the expression a && 5/a will never cause a division by zero, and the expression p && *p++ will never