mikel@codas.UUCP (Mikel Manitius) (10/10/85)
In Ratfor (a pre-processor to fortran (ugh!)) you can specify the level of
the break statement, meaning, out of how many loops you want to break,
thusly "break 2;" would break out of the current loop, and the one it is
nested within, I would on many occasions have liked to have had this feature.
--
=======
Mikel Manitius ==----===== AT&T
(305) 869-2462 RNX: 755 ==------===== Information Systems
...{akguc|ihnp4}!codas!mikel ===----====== SDSS Regional Support
...attmail!mmanitius =========== Altamonte Springs, FL
My opinions are my own. =======franka@mmintl.UUCP (Frank Adams) (10/22/85)
In article <195@codas.UUCP> mikel@codas.UUCP (Mikel Manitius) writes: >In Ratfor (a pre-processor to fortran (ugh!)) you can specify the level of >the break statement, meaning, out of how many loops you want to break, >thusly "break 2;" would break out of the current loop, and the one it is >nested within, I would on many occasions have liked to have had this feature. Better to put some kind of label on the statements being "broken" out of, end specify the label in the break statement. Otherwise, it's too easy to miscount -- especially with both loop and switch statements. Frank Adams ihpn4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (10/25/85)
In article <723@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <195@codas.UUCP> mikel@codas.UUCP (Mikel Manitius) writes: >>In Ratfor (a pre-processor to fortran (ugh!)) you can specify the level of >>the break statement, meaning, out of how many loops you want to break, >>thusly "break 2;" would break out of the current loop, and the one it is >>nested within, I would on many occasions have liked to have had this feature. > >Better to put some kind of label on the statements being "broken" out of, >end specify the label in the break statement. Otherwise, it's too easy >to miscount -- especially with both loop and switch statements. > >Frank Adams NOT THIS RECORD! NOT THIS RECORD!!! AHHHHHHRRRRRGGGHHHHHH!!!!!!!!!! This debate went on for months in this newsgroup recently. Please, let's not start it up again. Last time, the final decision was: some people like break <number>, and some people like break <label>, and some people don't like break at all ("it's not structured"), and some people like break as it is ("you should make it a function and return;"). I'm sure that if we debate it for a few *more* months we can add a fifth item, but ask youself: is this discussion *really* necessary? Ken Arnold
mikes@3comvax.UUCP (Mike Shannon) (10/29/85)
Advocates of 'break <label>' and 'break <nesting-level-number>' should
meditate a long time to be sure they are not trying to fool themselves.
These break statements are just a way to disguise a goto statement.
The only thing wrong with goto statements (I never use them) is
that they make code hard to understand. There are probably rare cases
when code is made more clear by the use of goto statements.
[...slips climbing off soap box]
--
Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikesweltyrp@rpics.UUCP (Richard Welty) (10/29/85)
> > In article <195@codas.UUCP> mikel@codas.UUCP (Mikel Manitius) writes: > >In Ratfor (a pre-processor to fortran (ugh!)) you can specify the level of > >the break statement, meaning, out of how many loops you want to break, > >thusly "break 2;" would break out of the current loop, and the one it is > >nested within, I would on many occasions have liked to have had this feature. > > Better to put some kind of label on the statements being "broken" out of, > end specify the label in the break statement. Otherwise, it's too easy > to miscount -- especially with both loop and switch statements. > > Frank Adams ihpn4!philabs!pwa-b!mmintl!franka as I recall, the Bliss leave statement did exactly that. In fact, the leave statement returned a value (bliss is really a expression language, so leave can return a value), which meant that a control structure could see why it terminated ... -- Rich Welty "P. D. Q.'s early infancy ended with a striking decision; at the age of three, P. D. Q. Bach decided to give up music" - Prof. Peter Schickele, from "The Definitive Biography of P. D. Q. Bach" CSNet: weltyrp@rpics ArpaNet: weltyrp.rpics@csnet-relay UUCP: seismo!rpics!weltyrp
preece@ccvaxa.UUCP (10/30/85)
> /* Written 7:22 pm Oct 28, 1985 by mikes@3comvax.UUCP in > ccvaxa:net.lang.c */ Advocates of 'break <label>' and 'break > <nesting-level-number>' should meditate a long time to be sure they are > not trying to fool themselves. These break statements are just a way > to disguise a goto statement. ---------- Do you also object (it's EXACTLY the same argument) to having more than one "return" statement in a function definition? -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece
ray@othervax.UUCP (Raymond D. Dunn) (10/31/85)
In article <258@3comvax.UUCP> mikes@3comvax.UUCP (Mike Shannon) writes: >.... > The only thing wrong with goto statements (I never use them) is >that they make code hard to understand. There are probably rare cases >when code is made more clear by the use of goto statements. Please! Goto statements do not *intrinsically* make programs hard to understand, although like all techniques, if an individual is not familiar with their use, then to him they may appear "more difficult". It is my experience that a programmer who does not have his logic clear can write just as obscure code using a structured language than a "goto'ed" language. Specifically, the use of goto's (and especially long jumps) to cut across normal program logic to handle exception processing, is to my mind, almost a necessity, and *certainly* simplifies the conditional structure of a program. This applies just as strongly to the ability to abort out of several levels of loops. Like most programming methods, the careful choice of label names and use of comments is the key to understandability. Ray Dunn. ...philabs!micomvax!othervax!ray
dgary@ecsvax.UUCP (D Gary Grady) (10/31/85)
> These break statements are just a way to disguise a goto statement. Why stop with break statements? The switch statement is just a way of disguising a multiway GOTO! While, for, and do statements are merely GOTOs and conditional GOTOs in Clever Plastic Disguises! > The only thing wrong with goto statements (I never use them) is > that they make code hard to understand. > Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes The reason true GOTO statements are hard to understand is that it is impossible to tell at a glance whither they go (up? down?) and it makes it damned hard at the target address to figure whence cometh the flow. By careful indentation (and the wise avoidance of the sin of long loops) one can avoid these failings of the GOTO and still have the advantages of break (and continue). For example: while ... { ...statements... if ... break; ...statements... } By the way, note how a reasonable word of advice ("don't use GOTOs") can be transformed by religious fervor into an absolute prohibition ("thou shalt not use GOTOs or anything that could be remotely construed as a GOTO, or thine arse is like unto the grass of the fields, thou sucker"). -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
dcm@busch.UUCP (Craig Miller) (11/01/85)
In article <2600026@ccvaxa> preece@ccvaxa.UUCP writes: > >Do you also object (it's EXACTLY the same argument) to having more >than one "return" statement in a function definition? > >-- >scott preece >gould/csd - urbana >ihnp4!uiucdcs!ccvaxa!preece (yet another of my pet peeves...) I object. I find a function that has lots of returns harder than hell to read. How can you call a function with 10 returns top down? Come on. There are a *few* exceptions when multiple returns makes a function more readable. If a function of mine looks more readable with multiple returns, I start looking for the problem within that function. Usually I tried to have the function do too much, and breaking the function into smaller, more concise functions fixes the problem. Btw, the same goes for programs with multiple exits (*especially* those that exit from within a function other than main. yuck). Almost all of my programs have one return statement in main. (my personal preference is return, but an exit doesn't bother me when called in main...) Whatever happened to top-down programming, anyway? Some people think that just because they program in C makes them structured programmers. Wrong. It still takes some effort. Maybe there ought to be a mailing list or a new group just on programming style? (and not necessarily just in C - a lot of style things don't depend on the language) Craig -- Craig Miller {*}!ihnp4!we53!busch!dcm The Anheuser-Busch Companies; St. Louis, Mo. - Since I'm a consultant here and not an Anheuser-Busch employee, my views (or lack of) are strictly my own.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/03/85)
> Do you also object (it's EXACTLY the same argument) to having more > than one "return" statement in a function definition? In theory, he should. The objection to break and return from the middle of a block is that there are then multiple exits from the block. This makes it more difficult to establish clean termination conditions and loop invariants for verifying the correctness of the code. Of course, few C programmers worry about this! :-)
tp@ndm20 (11/03/85)
>/* Written 10:15 am Oct 30, 1985 by preece@ccvaxa.UUCP in ndm20:net.lang.c */ >> /* Written 7:22 pm Oct 28, 1985 by mikes@3comvax.UUCP in >> ccvaxa:net.lang.c */ Advocates of 'break <label>' and 'break >> <nesting-level-number>' should meditate a long time to be sure they are >> not trying to fool themselves. These break statements are just a way >> to disguise a goto statement. >---------- >Do you also object (it's EXACTLY the same argument) to having more >than one "return" statement in a function definition? Yep. And for the same reasons. Terry Poot Nathan D. Maier Consulting Engineers (214)739-4741 Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp CSNET: ndm20!tp@smu ARPA: ndm20!tp%smu@csnet-relay.ARPA
peter@graffiti.UUCP (Peter da Silva) (11/04/85)
> In theory, he should. The objection to break and return > from the middle of a block is that there are then multiple > exits from the block. This makes it more difficult to > establish clean termination conditions and loop invariants > for verifying the correctness of the code. Of course, few > C programmers worry about this! :-) Generally because it's not practical to prove code correct in large scale applications. In fact it's hard to apply many computer science techniques in large scale applications. This is extremely unfortunate, but until CS people start using real-world problems as the basis of their theories it will remain true. -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
asw@rlvd.UUCP (Antony Williams) (11/07/85)
In article <402@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: >Generally because it's not practical to prove code correct in large >scale applications. I think what you really mean is that it is not YET practical to prove large scale applications wholly correct. It is certainly practical to prove correctness for smallish modules, and this is extremely beneficial: it means that you should look elsewhere for the bug, even if the symptom occurs in the verified module. The total program remains unproved, as the verification relies on the assumption that the module has not been interfered with by some other part of the program. The ubiquity of this phenomenon in C programs does not imply that formal verification has no benefit. > In fact it's hard to apply many computer science ^^^^^^^^^^^^^^^^ >techniques in large scale applications. This is extremely unfortunate, ^^^^^^^^^^ I tend to think of things like searching techniques as computer science techniques because one expects computer science graduates to have learned about them. You must have a different idea, or else I feel sorry for those who use/support/pay for your code :-) -- --------------------------------------------------------------------------- Tony Williams |Informatics Division UK JANET: asw@uk.ac.rl.vd |Rutherford Appleton Lab Usenet: {... | mcvax}!ukc!rlvd!asw |Chilton, Didcot ARPAnet: asw%rl.vd@ucl-cs.arpa |Oxon OX11 0QX, UK
zben@umd5.UUCP (11/08/85)
(For those who have just joined us, the topic under discussion is regarding the use of "break" and (multiple) "return" statements.) In article <918@rlvd.UUCP> asw@rlvd.UUCP (Antony Williams) writes: >In article <402@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: >>Generally because it's not practical to prove code correct in large >>scale applications. >I think what you really mean is that it is not YET practical to prove >large scale applications wholly correct. I avoid the use of short-circuit returns, not so much because of the provability angle, but because it really burns me up to put debugging output at the end of a procedure, go through all the hassle of compiling and linking the code, and then not getting any debug output because the silly procedure returned short. Just as it impacts the ease of debugging, this technique also impacts the ease of extending the code. This is another complaint against the "one-statement" model. It's really a drag to put in a { } pair just because you want to add debug printout (probably temporarily) in a "one-statement" context. I much prefer the Modula-2 "statement block" model. This is also a complaint against languages that require the semicolon be left off the last statement in a block. Of course, that's just where you want to put the debugging output, and as others have pointed out, 99% of the time you will NOT remember to put that semicolon back in. -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA
peter@graffiti.UUCP (Peter da Silva) (11/10/85)
> > In fact it's hard to apply many computer science > ^^^^^^^^^^^^^^^^ > >techniques in large scale applications. This is extremely unfortunate, > ^^^^^^^^^^ > > I tend to think of things like searching techniques as computer science > techniques because one expects computer science graduates to have learned > about them. You must have a different idea, or else I feel sorry for those > who use/support/pay for your code :-) OK, let me rephrase that to make my meaning clearer: There are many computer science techniques that are hard to apply in large scale applications. Does this make more sense? -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
franka@mmintl.UUCP (Frank Adams) (11/15/85)
In article <918@rlvd.UUCP> asw@rlvd.UUCP (Antony Williams) writes: >In article <402@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: >>Generally because it's not practical to prove code correct in large >>scale applications. >I think what you really mean is that it is not YET practical to prove >large scale applications wholly correct. I think he meant what he said. It may some day be practical to prove code correct in large scale applications. Then again, it may not. Frank Adams ihpn4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108