Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!ctrsol!emory!stiatl!tom
From: tom@stiatl.UUCP (Tom Wiencko)
Newsgroups: comp.lang.pascal
Subject: Re: Funny evaluation of functions
Message-ID: <6682@stiatl.UUCP>
Date: 29 Aug 89 12:23:28 GMT
References: <20715@adm.BRL.MIL> <616@lehi3b15.csee.Lehigh.EDU>
Reply-To: tom@stiatl.UUCP (Tom Wiencko)
Organization: Wiencko & Associates, Inc.
Lines: 42

In article <616@lehi3b15.csee.Lehigh.EDU> edkay@lehi3b15.csee.Lehigh.EDU (Ed Kay) writes:
>> 
>>I encountered the question in the context of wanting to write a procedure
>>that had a side-effect on the variable X, and I was being cautious about
>>when I accessed X.  I wanted to be sure that I accessed X after it had
>>been changed.  I originally wrote  WRITELN(OUTPUT,ONE(X)*X) to be sure
>>that X was changed and then became curious whether my caution was warranted
>>in Turbo 4.0.  In practice, I would opt for the version in this paragraph,
>>which in most (all?) compilers would yield the desired result.  In any
>>case, I left behind a large caution sign about the trickery I was 
>>indulging in.  (Please note, that the actual code I wrote was not the
>>example I originally posted, but the example catches the spirit of the
>>actual code.)
>> 

Edwin:

Just a personal opinion here, and not wanting to start a flame war, but...

IMHO, this sort of code should be banned unless absolutely necessary.  The
potential for problems (due to new compilers, new versions of old compilers,
new people maintaining the code who do not read comments, and so on) far
outweigh restructuring your statements to allow function evaluations to happen
in an orderly fashion.  In compilers with really fancy optimization techniques,
all sorts of things not much related to the target expression might have an 
effect on how that expression is evaluated, and in cases like that you will
find yourself someday tracking down wierd problems.  I fixed one of those 
one day, where the addition or deletion of one line of code *100* lines away
from the problem area made a difference due to some pecularilarities of the
compiler.

Using side effects of function calls is a perfectly good programming technique.
Depending on the "average" behavior of a particular compiler or a particular
implementation of something not specified in the language is not a good 
technique.

Tom


-- 
Tom Wiencko                                            (w) (404) 977-4515
gatech!stiatl!tom                                  Wiencko & Associates, Inc.