msb@sq.UUCP (10/26/87)
I argued that > > for (iterations = 0; upper - lower > epsilon; iterations++) was more C-style than the corresponding while-form. Chip Salzenburg (chip@ateng.UUCP) replied: > It is _not_ true that a "C programmer" will use a "for" loop whenever > possible. For example, I consider myself a fairly experienced C > programmer, and my personal rule is that only variables involved in loop > _control_ should appear in the for statement. I would amend this to "involved WITH loop control". If "iterations" was some variable that is also being modified throughout inside the loop, then I would probably prefer the while form. But here it is a simple counter of the number of times the loop runs, which is more closely involved with loop control than with the loop body. It is a fairly fine point, until the loop body gets large enough that the iteration++ moves out of sight of the iteration=0. (Of course, depending on the use of break, one may be able to put the iteration++ at the TOP of the loop body, which is okay.) Anyway, further discussion on this should probably be by mail (so I'm putting "Followup-To: poster" in the header; override if you wish). Mark Brader "We did not try to keep writing until things got full." utzoo!sq!msb, msb@sq.com -- Ritchie
decot@hpisod2.HP.COM (Dave Decot) (11/11/87)
> >For example, if identifiers > >for function definitions occur against the left margin but most other > >text is indented, then it is easy with most text editors to quickly > >jump to the beginning of any function whose name is known, or to > >grep a set of sources to find out which one defines the function (as > >opposing to calling it). > > Which is why all my functions are declared as follows: > > int > myfunction() > { > } > > and not: > > int myfunction() > { > } Use of the program ctags(1) makes this unnecessary, keeps track of which function is in which file for easy jumping, and works even for code imported from elsewhere that did not use this convention. Dave Decot hpda!decot
tlg@ukc.ac.uk (T.L.Goodwin) (10/17/90)
In article <1990Oct17.030157.460@ux1.cso.uiuc.edu> gordon@osiris.cso.uiuc.edu (John Gordon) writes: > Also, one other thing: for() and while() loops are essentially >identical. The following loops are exactly the same: > >#1) for(i = 0; i < 100; i++) > { > body of loop > } > >#2) i = 0; > while(i < 100) > { > body of loop > i++; > } Almost, but not quite. If the body of the loop contains a "continue", then the second example becomes an infinite loop (other changes to i and "break"s notwithstanding), since the increment is never reached. John is not alone: this equivalence is wrongly claimed in Steve Bourne's book "The UNIX System", and also K&R (2, I haven't got a copy of 1 handy), although Bjarne Stroustrup gets it right in the C++ reference manual. Regards, Tim Goodwin.
seanf@sco.COM (Sean Fagan) (10/20/90)
In article <2226@ukc> tlg@ukc.ac.uk (T.L.Goodwin) writes: >Almost, but not quite. If the body of the loop contains a "continue", >then the second example becomes an infinite loop (other changes to i >and "break"s notwithstanding), since the increment is never reached. #define while(cond) for(;cond;) (I'm sitting here trying to think of any case where this will break [no pun intended 8-)] something; I can't think of any, offhand.) If you have something such as while () { whatever; } this will be an infinite loop given the macro, but a syntax error otherwise. But that's all I can think of... (I've wondered why C had while, because of this. The only think I could think of was that for came after while, and They didn't want to break existing code... Any commentators? [Henry? Chris? Doug? Dennis?]) -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (10/22/90)
In article <8308@scolex.sco.COM>, seanf@sco.COM (Sean Fagan) writes: > #define while(cond) for(;cond;) > > (I'm sitting here trying to think of any case where this will break > [no pun intended 8-)] something; I can't think of any, offhand.) Here's one: do i++; while (p(i)); > If you have something such as > while () { > whatever; > } > this will be an infinite loop given the macro, but a syntax error otherwise. In gcc it's a syntax error. In a guide to ANSI C that I have before me, it says that "a macro argument is ONE or more preprocessing tokens. I think this was a nasty thing for the committee to do: it is the one thing which has broken most of my code. Yes, the standard _does_ permit the definition of macros that look like functions with no arguments: #define no_arg_mac() stuff ... no_arg_mac() ... unfortunately old preprocessors that were happy with no tokens in an argument tended to be unhappy with no arguments in a definition. So I have to do #ifdef __STDC__ #define no_arg_mac() stuff #else #define no_arg_mac(DUMMY) stuff #endif Snarl. (Naturally, I figured out how to do that _after_ I'd added dummy arguments to the invocations in the files I really cared about. Sigh.) -- Fear most of all to be in error. -- Kierkegaard, quoting Socrates.
henry@zoo.toronto.edu (Henry Spencer) (10/22/90)
In article <8308@scolex.sco.COM> seanf (Sean Fagan) writes: >#define while(cond) for(;cond;) > >(I've wondered why C had while, because of this. The only think I could >think of was that for came after while, and They didn't want to break >existing code... Any commentators? [Henry? Chris? Doug? Dennis?]) Do bear in mind that the whole preprocessor was an afterthought, and did not exist in the original implementation. -- The type syntax for C is essentially | Henry Spencer at U of Toronto Zoology unparsable. --Rob Pike | henry@zoo.toronto.edu utzoo!henry
ag@cbmvax.commodore.com (Keith Gabryelski) (10/23/90)
In article <8308@scolex.sco.COM> seanf (Sean Fagan) writes: >#define while(cond) for(;cond;) > >(I'm sitting here trying to think of any case where this will break >[no pun intended 8-)] something; I can't think of any, offhand.) do { WHATEVER(); } while(COND); Pax, Keith
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (10/25/90)
seanf@sco.COM (Sean Fagan) writes: > #define while(cond) for(;cond;) > (I'm sitting here trying to think of any case where this will break [no > pun intended 8-)] something; I can't think of any, offhand.) How about this one? do { /* my code here... */ } while (cond); ----------------- Jeffrey Hutzelman America Online: JeffreyH11 Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu, jh4o@cmuccvma >> Apple // Forever!!! <<