Short-circuit evaluation of conditional expressions and delay evaluation of functions

The delay evaluation is. NET is a very important feature in Lisp language, this feature relies on macros to do, in c,c++, can be done by a function pointer, and in. NET, it is done by a delegate. If you don't understand what a deferred evaluation is, let's take a look at the following code:

      Static void testdelayfunction ()        {            TestDelayFunton1 (true, trueFun3);        }         Static void TestDelayFunton1 (bool flag, func<bool> fun  )        {            if  (flag) fun               ();        }

In method TestDelayFunton1, the function-type parameter fun is evaluated, depending on the first parameter, flag, if its value is false, then the function fun is never evaluated, so, here the function The evaluation of fun is deferred to the interior of the method TestDelayFunton1, not when the parameter is calculated.

Delay evaluation is useful, it can avoid our useless calculation, such as the above example, this can save the computational cost, if the fun evaluation is time-consuming.

Let's take a look at this section of code:

if (flag) fun   ();

In fact, it is equivalent to a logical expression:

bool result= flag && Fun ();

In this expression, whether the fun () function evaluates, depends on the variable flag, this function is called "short-circuit" judgment, "conditional short-circuit" function just realizes our "delay evaluation" function, so we can get the following inference:

At any time a function fun can be expressed as a conditional expression if a delay evaluation is required:

(Test () && fun ())

So, the previous 2 functions, in essence, can be rewritten as one of the following functions:

      Static void TestDelayFunton2 (bool  flag)        {            bool result = Flag && trueFun3 ();        }

It will TestDelayFunton1 (TRUE,TRUEFUN3); In the form of a call, converted to a function call above.

Of course, to make this call available, we also need to solve a problem, that is, the type of function fun () is not a bool type, the problem is very simple, the function can be repackaged:

BOOL warpfunction () {fun  ();   return true ;}

The subsequent call will look like this:

(Test () && warpfunction ())

For this example, it is actually equivalent to:

(Flag && trueFun3 ())

If it is a "smart" compiler, it is possible to complete the above conversion, the following gives a complete code picture, so you can see more clearly:

The 2 functions of the marked section above are equivalent to the following function.

If you're still not sure about the process above, let's take a look at the following example:

 Static BOOLtrueFun1 () {Console.WriteLine ("Call Fun 1"); return true; }        Static BOOLfalseFun2 () {Console.WriteLine ("Call Fun 2"); return false; }        Static BOOLTrueFun3 () {Console.WriteLine ("Call Fun 3"); return true; }

Execute the following code, will the TRUEFUN3 be executed?

if (TrueFun1 () && falseFun2 () && (TrueFun3 ())) {             } Console.WriteLine (); if (TrueFun1 () | | falseFun2 () | | TrueFun3 ()) {}

If you understand the "conditional short-circuit" feature of C # very well, I believe the answer will come out soon.

After reading this article, you may ask what is the effect of such a strange trick?

If you look into it. NET delegate, you will understand that the delegate invocation is actually wrapping a function with the object. NET automatically generated a lot of code for you, performance, such as loss, to join you in some places need the ultimate performance of the code, then this article this technique will help you, join you can also write a compiler for this conversion, congratulations, the future of the Great God is you!

Short-circuit evaluation of conditional expressions and delay evaluation of functions