aha!
this explains a lot.
+1
this should really be a priority for a hot fix
I think I have an idea how to fix this problem. **Temporary variables and the comma operator! **
Instead of āreturn A && B;ā you should write
ābool ABool, BBool;
return (ABool=A), (BBool=B), (ABool && BBool);ā
I think this would make it so that it would tell the compiler to force a sequence of actions.
Just have been following the discussion and like to add my 2 cents 
Short circuit evaluation can speed up certain things, but also has its caveats.
For example if evaluation of the second term in the boolean AND expression is doing more than just evaluating.
Sometimes I write code where functions evaluate something but also does āglobalā stuff. Not a nice style, I know, but it sometimes really simplifies coding a lot.
In Delphi I mostly use short circuit evaluation and use a compiler switch to enable āfullā evaluation on a case by case base.
So, if implemented, it should be possible to choose the evaluation methodā¦
First of all, thanks for mentioning short circuit evaluation. My intuitive solution was to chain my nodes, which produces a lot of ugly code but it definitly speeds things up.
I think its always good to make things more strict. If there is a better way to do something, everybody should be forced to do it like this. Everything else would end up in ugly and slow code.
In my opinion, logical operators are not made to execute code whichs modifies the state of your program.
That is what I meant by āNot a nice styleā 
Anyway, its not the operators that are the issue, but the evaluation of the operands. Te operators just define the operation and precedence rules govern their order.
Cases where, whilst evaluating an operand of a boolean expression, a program modification can simplify things are recursive tree travelling where some data is accumulated in a globally accessible listā¦
Calm down, we get it. My point was itās already possible so I didnāt see what OP said was missing as such. Like SaxonRah says, you stagger the branch nodes.
Depends on the situation though, you might be performing an op on a variable using pass-by-reference, and returning based on what happens.
I donāt see any reason NOT to have this, though so long as there are no major hits in flexibility taken by doing so. It should be off by default too, most Blueprint users probably have no idea what SCE is, and usually wonāt ever need to.
I noticed this with the Select nodes as well. It evaluates every pin before selecting the result. Itās very annoying, since it forces you to use execution branching inside otherwise pure functions/macros and in large select nodes it can cause unexpected performance overhead.
I assume this is a side effect of how BP nodes work: they take all the pins, feed it into their underlying C++ function and then grab the output. Implementing short-circuiting would require a node to have a different kind of logic where it executes a function for each pin sequentially (boolean operations) or evaluate a specific pin and execute a function to decide which pin(s) to evaluate next (the select node).
On the other hand it produces a āstableā evaluation speedā¦
I think itās fine the way it is, where simplicity is more important than brevity.
99.9% of the time, short-circuit evaluation would not change the running speed of a blueprint.
If you have a profiler that shows that in some particular case, it actually matters, then you should probably make this explicit in the blueprint by using an explicit second Branch node.
And the mantra has been: if performance really matters, write it in C++ā¦
That is trueā¦
But soon we will see all the BP being converted to c++ and then this no longer applies
2 Likes
Thereās always 2 extreme spectrum of doing things in unreal. Always have been. The editor guys and the programmer advocates.
True that certain thing isnāt feasible to be done in BP. But I donāt believe this as one of it.
So yes Iām a greedy cake-eater , I want like good performance , but I donāt want to let go of the other benefits in BP.
Yes, in short, i want the cake and eat it too , but Iām trying not to throw a tantrum in the cakeshop while knocking over the other pastries.
Asking nicely is as far as I would go.
yeapā¦ All the cakeā¦ every last bite of itā¦
I just came across the same issue with the āORā node, scratched my head for a while and realized that there is no āshort-circuitā evaluation for the logical nodes in Blueprint. Had to chain two āBranchā nodes to achieve what I needed. Would be good if BP supported the SC evaluation. However, there might be a reason since a considerable nowadays BP users are not programmers, they might not understand or just not used to this concept as we true programmers do. (15 yrs C++ experience here). So chaining two āBranchā nodes seems more explicit on whatās happening.
People arguing over performance and logspam are completely misguided.
Yes if BP accesses a null pointer it will just warn you. But if your second statement is some call to a C++ pure function that relies on something not being null, if THAT accesses a null pointer because it didnāt get short circuited, youāll crash. Yes, you can stagger the branches and thatās how all of us did the workaround but the biggest problem here is consistency. Itās being short circuited in most āgrown upā programming languages, it makes sense to be short circuited in BP, as thatās just programming too.
I agree with you for the most part. But when we write code in C++ (or other mature languages with SC), the ordering of execution is strictly following how we write it. However, in BP, the positioning of the nodes (top-down or left-right) doesnāt signify the evaluation order, it is the order of the pins that determines the evaluation order. BUT (big BUT), since BP is visual, we have run into situations that sometimes we as users connect the āupperā evaluation node to the lower pin, and ālowerā node to the upper pin (yes, two connectors cross each other) - sometimes itās just easier to rearrange connectors than repositioning nodes! So a careless viewer of the BP might assume that the upper node is the first condition to evaluate, and the lower node is the second condition, without ever noticing that the pins are connected in the reverse order. Confusion thus arises.
I am not saying I am not voting to have SC for BP, but the above might be the case that BP is not exactly as obvious or semantically strict as code. Just my 2 cents, and not intending to start a flame war. 
Iāve programmed in C++ over 15 years, yet I can still see an argument for not shortcircuiting in blueprint. I donāt think itās a no-brainer that it should do it ābecause most languages doā. Most languages arenāt visual scripts for one thing. The behavior of the select node on the other hand (evaluating all inputs), I donāt think anyone could call that more intuitive.
Anyway, the discussion of what people expect is kind of irrelevant - this is all a result of how blueprint pure functions are dealt with in general. See this discussion here.
Essentially, when a node needs evaluating, it acts like a single function call in C++ would - it evaluates all the passed in arguments first, before executing its logic. If any inputs are wired from a pure node, the same thing happens recursively. As explained in the linked thread, not only will this mean every connected input will evaluate, but it can mean that some pure nodes get evaluated multiple times.
Iām not exactly a fan of this, but I can see why it would work this way in a visual language. It would be pretty confusing if this evaluation behaviour was different just in the case of a few specific nodes. It would also likely break just about every blueprint written to date if it were changed now.
Coming back to this after god knows how long, I agree. Short circuit evaluation would be useful.
Hi !
So you are saying that BP is a complete waste of time. Iām breaking my head trying to figure BP, instead of learning C ++? And in future UE4 will become something like Unity, full of plugins?
Do not take bad. Iām not disagreeing with you. You are a prophet . I remember when you talked about Trello and Marketplace. You seem to be having a clear vision about future BP, with very fews intuitive nodes, and many features for non programmers. This looks wonderful! So Iām going to dedicate myself more time to my art, character modeling, rigging, texturing, and animation.
No to all points. Learning C++ doesnāt prevent you learning Blueprint (and if you know C++, you should know Blueprint pretty well at that stage anyway), any programmer should try to learn both as best as they can.
Additionally, the BP to C++ converter wonāt work as well as everybody seems to think it will. It literally does dumb copy-paste from the engine source files. In most cases it will still be just as slow if not slower. If you want the utmost in performance, learn C++ properly.