jharkins@sagpd1.UUCP (Jim Harkins) (06/08/90)
Lets say you have the following (you ADA people, please bear with me): #define SIZE 6 #define STEP 2 Which is better: a. for(i = SIZE; i != 0; i -= STEP) or b. for(i = SIZE; i > 0; i -= STEP) Where this makes a difference is suppose SIZE is changed to 7. Obviously 'a' goes into an infinite loop, while 'b' stops. In the real world SIZE and STEP could be variables that have been input by a user and manipulated a gazillion times before being used in the for loop. With method 'a' a bug is easy to spot, thus easy to fix. But the bug may not appear at a good time, the user may prefer that his system limp along rather than hang completely. With method 'b' the bug is harder to spot. If you test your code well you should catch these things, but a man named Murphy became famous anyway. I believe method 'b' is preferred by 'defensive programmers'. It is also possible that with method 'b' the loop body stomps over somebody elses memory, with unknown but probably bad results. So, how do you all feel about this? As I'm writing for a military contract I've cross-posted this to comp.lang.ada, I hope they don't get too upset. And please hurry, this came up for a reason :-) -- jim jharkins@sagpd1 I hate to see you go, but I love to see you walk away.
sampson@cod.NOSC.MIL (Charles H. Sampson) (06/08/90)
In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes: > >Lets say you have the following (you ADA people, please bear with me): > > #define SIZE 6 > #define STEP 2 > >Which is better: > > a. for(i = SIZE; i != 0; i -= STEP) >or > b. for(i = SIZE; i > 0; i -= STEP) > >Where this makes a difference is suppose SIZE is changed to 7. Obviously >'a' goes into an infinite loop, while 'b' stops. In the real world SIZE and >STEP could be variables that have been input by a user and manipulated a >gazillion times before being used in the for loop. > Neither is inherently better than the other; it depends on the problem. If the problem requires that SIZE be a multiple of STEP, then a is preferable because it reflects the problem requirement, but the requirement itself must be validated at some point. If there is no required relation between SIZE and STEP, then b reflects that fact and is preferable. (Of course, a is wrong in the latter case, so b is strongly preferable.) All of this is MHO, naturally. Charlie Sampson, CSC P. S. Anything written down here can be ignored. The poster would not ac- cept my followup because I had included more than I had written. Strange, I thought I had cut down the original article to the minimum needed to es- tablish the context, then gave a compact response. Apparently that's not good enough. The only solution in such a case seems to be to pad your followup enough to get past that limitation. Seems to me that the limita- tion is self-defeating. This is the end of my first try at padding.
t-wader@microsoft.UUCP (Wade Richards) (06/12/90)
In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes:
=}
=}Lets say you have the following (you ADA people, please bear with me):
=}
=} #define SIZE 6
=} #define STEP 2
=}
=}Which is better:
=}
=} a. for(i = SIZE; i != 0; i -= STEP)
=}or
=} b. for(i = SIZE; i > 0; i -= STEP)
=}
It depends on the situation.
If you know that i will exactly equal zero (as in this case), then I think
that's what you should test for. However, I would probally put:
assert( SIZE % STEP == 0 )
before the loop, to make sure nothing blows up, and (more importantly) to make
it quite clear what was at fault if it does blow up.
--- Wadefirth@sei.cmu.edu (Robert Firth) (06/12/90)
In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes: >Which is better: > > a. for(i = SIZE; i != 0; i -= STEP) >or > b. for(i = SIZE; i > 0; i -= STEP) > >Where this makes a difference is suppose SIZE is changed to 7. Obviously >'a' goes into an infinite loop, while 'b' stops. In the real world SIZE and >STEP could be variables that have been input by a user and manipulated a >gazillion times before being used in the for loop. First, the coding of the loop should have nothing to do with the values of SIZE and STEP. The code you write should be determined by the postcondition you wish to establish. If the required postcondition is "i=0" then the correct continuation test is "i/=0"; on the other hand if the required postcondition is "i<=0" then the test is "i>0". This would all be much clearer in a language that allowed the condition to be written positively, thus: loop ... exit when i=0 end loop -- postcondition: i=0 Secondly, the question of errors. If the loop variable reaches a state from which the postcondition is unreachable, there is an error in the code. For example, if the postcondition is "i=0", the recurrence relation "i'<i" (ie the new value of i will be strictly less than the old value), and the current value of i is negative, then the postcondition will never be reached. If you suspect this can happen, you should test for the situation, *but this test should be separate from the loop termination test and not merged with it*. The reason is that, if the test fails, the last thing you want to do is terminate the loop silently with the postcondition false. You probably want to raise an exception, enter a recovery block, or take some similar emergency action. Hope that helps.
brnstnd@kramden.acf.nyu.edu (06/14/90)
In article <7498@fy.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: > In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes: > > a. for(i = SIZE; i != 0; i -= STEP) > > b. for(i = SIZE; i > 0; i -= STEP) > First, the coding of the loop should have nothing to do with the values > of SIZE and STEP. The code you write should be determined by the > postcondition you wish to establish. Say what? Who cares what the value of i is after the loop? Most of the time I want to see i uninitialized the moment the loop ends (though there are enough exceptions to this rule that I don't want the language to force it on me). > Secondly, the question of errors. If the loop variable reaches a state > from which the postcondition is unreachable, there is an error in the > code. Again, who says there has to be a postcondition? The programmer is thinking about the values i will take on trips through the loop, not about the value it'll have afterwards. ---Dan
kassover@minerva.crd.ge.com (David Kassover) (06/14/90)
In article <23471:Jun1405:22:1090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu writes: >In article <7498@fy.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >> In article <811@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes: >> > a. for(i = SIZE; i != 0; i -= STEP) >> > b. for(i = SIZE; i > 0; i -= STEP) >> First, the coding of the loop should have nothing to do with the values >> of SIZE and STEP. The code you write should be determined by the >> postcondition you wish to establish. > >Say what? Who cares what the value of i is after the loop? ... >Again, who says there has to be a postcondition? The programmer is >thinking about the values i will take on trips through the loop, not >about the value it'll have afterwards. That would depend on the loop contents and the programmer, now wouldn't it? And in some sense the analyst who wrote the specification for a task that the programmer chooses to solve with the loop. Of course, if one is of the school of thought that a loop must have only one entrance and only one exit, one has to put in additional code and a different variable from the loop control variable to indicate, say, an index into a structure of a particular feature of that structure. And possibly waste large amounts of cycles searching the entire structure for information that is already found, and possibly will not be found. Ada has control structures that help with both scenarii (I'm assuming scenario is from the Italian 8-). This was crossposted to comp.lang.ada, and comp.lang.c. Since I don't read the latter, I have not followed up there. -- David Kassover "Proper technique helps protect you against kassover@ra.crd.ge.com sharp weapons and dull judges." kassover@crd.ge.com F. Collins