Announcement

Collapse
No announcement yet.

Please implement Short-Circuit evaluation for Blueprint

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [FEATURE REQUEST] Please implement Short-Circuit evaluation for Blueprint

    Blueprint scripting has no Short Circuit this is bad when I am doing AND evaluation for multiple pure functions.
    I hope Epic could implement it.


    For those who are not sure,
    Short Circuit is a term used to describe situation where :

    If you evaluate Cond1 AND Cond2 . If Cond1 fails , Cond2 does not get run at all.
    Which is a common knowledge for programmers.
    Last edited by Frozenfire; 09-12-2015, 02:52 AM.
    Developer at AmmoboxStudios.



    Eximius ( An FPS/RTS Hybrid )

    #2
    Need more explanation on this really... do you have a screenshot of the Blueprint or code snippet you're talking about? AFAIK, Blueprint Pure functions get run only if you 'call' them by plugging the output into something. If the output isn't *requested*, it won't run at all.

    Comment


      #3
      Originally posted by TheJamsh View Post
      Need more explanation on this really... do you have a screenshot of the Blueprint or code snippet you're talking about? AFAIK, Blueprint Pure functions get run only if you 'call' them by plugging the output into something. If the output isn't *requested*, it won't run at all.
      What he means is this:

      Code:
      if(evaluateStuff() && evaluateMoreStuff()) {
      ...
      }
      If evaluateStuff() returns false, the whole if clause is evaluated to false. Usually in most (if not all) mainstream languages the evaluateMoreStuff() function wouldn't be called at all since there is no need to. What Frozenfire means is that in blueprints the second operand is evaluated also, as in evaluateMoreStuff() is called even though the first operand (evaluateStuff()) returned false.

      This is problematic because without short circuiting conditional evaluating you can't do following for example:

      Code:
      Pseudo code
      List mylist = getList();
      If(mylist != null && !mylist.isEmpty()) { //error, trying to call isEmpty() on null variable
                                                                 //if mylist is null and expression doesn't short circuit
      
      }

      Comment


        #4
        i dont understand what is short circuit
        but i found is select node still get all data even if dosnt need to be called.
        like here, interface get health would be called and would spam warnings in output log like crazy until character not created.
        Last edited by CriErr; 09-11-2015, 09:19 AM.

        Comment


          #5
          Originally posted by CriErr View Post
          i dont understand what is short circuit
          but i found is select node still get all data even if dosnt need to be called.
          like here, interface get health would be called and would spam warnings in output log like crazy until character not created.
          https://en.wikipedia.org/wiki/Short-circuit_evaluation

          Comment


            #6
            Yeah I see, so if the function returns NULL instead of True or False, you want the statement to return false?

            Comment


              #7
              The more obvious example is with a pointer:
              Code:
              SomeType* Ptr = GetSomeObject();
              
              if (Ptr && Ptr->DoSomeMethod())
              {
                // do something
              }
              Without short circuiting you'll get a classic memory violation error.

              Comment


                #8
                Well, Blueprint handles this gracefully anyway right? For example it doesn't crash if you try to access an out-of-bounds element of an Array, it just warns you instead. In the case of Pointers, you can just do 'IsValid' and follow one execution path or a different one.

                I could be wrong but it just seems like a workaround for possibly dodgy code? If you didn't want to check the pointer because you never want it to NOT be valid at that point, you just trigger an Assertion instead right? There is already an Is Valid PURE function in BP that returns a bool too, so you just plug that into one AND and whatever else into the other right?

                I dunno, maybe I'm missing something.

                Comment


                  #9
                  Originally posted by TheJamsh View Post
                  Well, Blueprint handles this gracefully anyway right? For example it doesn't crash if you try to access an out-of-bounds element of an Array, it just warns you instead. In the case of Pointers, you can just do 'IsValid' and follow one execution path or a different one.

                  I could be wrong but it just seems like a workaround for possibly dodgy code? If you didn't want to check the pointer because you never want it to NOT be valid at that point, you just trigger an Assertion instead right? There is already an Is Valid PURE function in BP that returns a bool too, so you just plug that into one AND and whatever else into the other right?

                  I dunno, maybe I'm missing something.
                  Those are single examples of the problem. The real problem is that the boolean expression operands might cause side effects even if they're pure or not and people are (rightfully) assuming that they are evaluated in a similar short-circuiting way as normal C++ code. I assumed it works that way and I'm guessing I'm not the only one.

                  Comment


                    #10
                    type AND you will get AND node.
                    https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

                    Comment


                      #11
                      I think people don't understand very well what is happening there... Here is probably best example in pseudo code:

                      bool function A() { print("Function A Called"); return false; }
                      bool function B() { print("Function B Called"); return true; }

                      function TestShortCircuit()
                      {
                      if( A() && B() )
                      { print("Condition is true"); }
                      else
                      { print("Condition is false"); }
                      }
                      When you call function TestShortCircuit in C++ your output log will be:

                      Function A Called
                      Condition is false
                      When you construct same condition using blueprint node your log will be:

                      Function A Called
                      Function B Called
                      COndition is false
                      because blueprint is probably not wise enough to detect that condition can never be true when first function (A) returned false.

                      I belive it is "by design" because Epic doesn't like forcing people to take care of order of input pins for pure functions... But yes, some AND node with Short Circuit implemented will make conditions nicer and life will be easier!
                      Last edited by nonder; 09-11-2015, 02:53 PM.

                      Comment


                        #12
                        cmon guys, even i got the idea =)

                        Comment


                          #13
                          Yeah I see what you're saying now, though technically, it's still possible just with a longer 'chain' of nodes. But yeah kind of annoying then...
                          Last edited by TheJamsh; 09-11-2015, 04:06 PM.

                          Comment


                            #14
                            here's a better way of explaining it.

                            1)It has nothing to do with stability or crashing.
                            2) Very applicable if you extensively use 'Pure' Functions ( I do ) , 'Non-Pure' functions will run regardless when exec nodes are hit.
                            3) This solves a lot of Accessed 'None' spamlogs. Chasing them down isn't fun.


                            Click image for larger version

Name:	Short Circuit.jpg
Views:	1
Size:	256.2 KB
ID:	1087458


                            *forgive my spelling and typos. I'm using paint and i'm too lazy to remake the pic
                            Developer at AmmoboxStudios.



                            Eximius ( An FPS/RTS Hybrid )

                            Comment


                              #15
                              Wow I thought this happened by default in BP never actually tested this.

                              +1 this.

                              It means you can prioritize those conditions so Condition 1 is the Condition that will most likely be false and if this is the case stop executing further code. Like you say Branch is the easiest way round this but It soon begins unorganized and, illogical.

                              Comment

                              Working...
                              X