next up previous contents
Next: Argument Intent Up: More on Procedures Previous: Recall F90 Program Units   Contents

Side Effects

A notorious characteristic of bad software design are the side effects. Side effects may happen when a function or subroutine modifies the values of their input arguments, the result being a hard-to-control program logic.

For example, suppose we want a function norm2w (w stands for wrong!) which computes the 2-norm of the vector, then projects the vector on the (y,z) plane by setting its x-coordinate to zero.

At some point in the program we have 2 vectors which have the same (x,y) coordinates, but a different z coordinate, and . To fix the ideas, suppose , , , and . Our intent is to compute the norm of the first vector ( ) plus the norm of the (y,z) projection of the second vector ( ). The correct result is .

We write the following line of code:

y = norm2w(a,b,c) + norm2w(a,b,d)
When the first call is executed, is computed, then is set to 0; at the second call, is computed, and is set again to zero; overall, we get the correct result.

Now, the trouble is that we do not know that norm2w(a,b,c) is evaluated first, and norm2w(a,b,d) second. Except for operator precedence, F95 standard says nothing about the order of argument evaluation. The compiler may choose to evaluate the right operand first (i.e. norm2w(a,b,d)), put the result in temporary storage, evaluate the left operand next (i.e., norm2w(a,b,c)) and then perform the addition. Now the result is , clearly different than what we had in mind.


next up previous contents
Next: Argument Intent Up: More on Procedures Previous: Recall F90 Program Units   Contents
Adrian Sandu 2001-08-26