shearer@cis.udel.edu (Rob Shearer) (09/26/90)
As one of my old C Profs stated: "If you don't like the way "C" is..
find yourself a new language.... don't take MY "C" away from me..."
If I wanted to do something ... I should be able to do it. If I made a stupid
mistake, then that is my fault. "C" gives one the power to do what s/he wants
not what another program (Compiler) regulates...
As for the break from the switch sin... ( i disagree with most of the sins..
except for 8char variables.. but then again... my compiler allows 32)
I do this alot:
ch = getch();
switch (ch) {
case 'q':
case 'Q':
case 27 :
case 13 :
exit_menu = 1;
break;
case 'a':
do_a(); break;
...etc
}
And personally I don't care if you want to do switch (upcase(ch)) { and
have a differetn case for Q,27,13... that is yoru business... but the way
*I* want to do it is up to me...
Robb Shearer
shearer@sol.cis.udel.eduvolpe@underdog.crd.ge.com (Christopher R Volpe) (09/27/90)
In article <31604@nigel.ee.udel.edu>, shearer@cis.udel.edu (Rob Shearer) writes: |> |>I do this alot: |> |> ch = getch(); |> switch (ch) { |> case 'q': |> case 'Q': |> case 27 : |> case 13 : |> exit_menu = 1; |> break; |> case 'a': |> do_a(); break; |> ...etc |> } How about combining the "let's make break implicit" idea with the "lets add ranges and lists" idea and solve everybody's problems? E.g.: ch = getch(); switch (ch) { case 'q','Q',27,13: exit_menu=1; case 'a': do_a(); ...etc } Now, a break within a case can be used to break out of an enclosing loop, and the "multi-case" capability is still maintained. ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
daves@hpopd.HP.COM (Dave Straker) (09/27/90)
/ hpopd:comp.lang.c / shearer@cis.udel.edu (Rob Shearer) / 4:02 pm Sep 26, 1990 /
As one of my old C Profs stated: "If you don't like the way "C" is..
find yourself a new language.... don't take MY "C" away from me..."
If I wanted to do something ... I should be able to do it. If I made a stupid
mistake, then that is my fault. "C" gives one the power to do what s/he wants
not what another program (Compiler) regulates...
As for the break from the switch sin... ( i disagree with most of the sins..
except for 8char variables.. but then again... my compiler allows 32)
I do this alot:
ch = getch();
switch (ch) {
case 'q':
case 'Q':
case 27 :
case 13 :
exit_menu = 1;
break;
case 'a':
do_a(); break;
...etc
}
And personally I don't care if you want to do switch (upcase(ch)) { and
have a differetn case for Q,27,13... that is yoru business... but the way
*I* want to do it is up to me...
Robb Shearer
shearer@sol.cis.udel.edu
----------daves@hpopd.HP.COM (Dave Straker) (09/27/90)
> As one of my old C Profs stated: "If you don't like the way "C" is.. > find yourself a new language.... don't take MY "C" away from me..." > > If I wanted to do something ... I should be able to do it. If I made a stupid > mistake, then that is my fault. "C" gives one the power to do what s/he wants > not what another program (Compiler) regulates... > > Robb Shearer > shearer@sol.cis.udel.edu $flame on! Are you a student? Has you Prof ever programmed professionally? One day, you may have to maintain code written by people who do it 'their way'. Then words like standards, simplicity, clarity and portability will become more important. You write code to be read and maintained, not just to be executed! $flame off Dave Straker Pinewood Information Systems Division (PWD not PISD) [8-{) HPDESK: David Straker/HP1600/01 Unix: daves@hpopd.hp.com
jmann@angmar.sw.stratus.com (Jim Mann) (09/27/90)
In article <12180@crdgw1.crd.ge.com>, volpe@underdog.crd.ge.com (Christopher R Volpe) writes: |>In article <31604@nigel.ee.udel.edu>, shearer@cis.udel.edu (Rob Shearer) |>writes: |>|> |>|>I do this alot: |>|> |>|> ch = getch(); |>|> switch (ch) { |>|> case 'q': |>|> case 'Q': |>|> case 27 : |>|> case 13 : |>|> exit_menu = 1; |>|> break; |>|> case 'a': |>|> do_a(); break; |>|> ...etc |>|> } |> |>How about combining the "let's make break implicit" idea with the |>"lets add ranges and lists" idea and solve everybody's problems? E.g.: |> |>ch = getch(); |>switch (ch) { |> case 'q','Q',27,13: |> exit_menu=1; |> case 'a': |> do_a(); |> ...etc |>} |> This still doesn't do everything you might want. It doesn't handle the situation in which you do something for one case and then fall through to the next to do some additional stuff: switch(ch) { case 'a': do_a(); case 'b': do_a_or_b(); break; . . . } Jim Mann Stratus Computer jmann@es.stratus.com
volpe@underdog.crd.ge.com (Christopher R Volpe) (09/28/90)
In article <2487@lectroid.sw.stratus.com>, jmann@angmar.sw.stratus.com (Jim Mann) writes: |>This still doesn't do everything you might want. It doesn't handle |>the situation in which you do something for one case and then |>fall through to the next to do some additional stuff: |> |>switch(ch) |> { |> case 'a': |> do_a(); |> case 'b': |> do_a_or_b(); |> break; |> . |> . |> . |> } Ok, how about requiring the programmer to make it explicit when he/she wants it to fall through, rather than making that the default? Like so: switch(ch) { case 'a': do_a(); continue; case 'b': do_a_or_b(); } or perhaps allow matching more than one case: switch(ch) { case 'a': do_a(); case 'a','b': do_a_or_b(); } This probably belongs in alt.lang.cfutures... |> |>Jim Mann |>Stratus Computer |>jmann@es.stratus.com ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (09/28/90)
volpe@underdog.crd.ge.com (Christopher R Volpe) writes > Ok, how about requiring the programmer to make it explicit when > he/shewants it to fall through, rather than making that the default? > Like so: > >switch(ch) > { > case 'a': > do_a(); > continue; > case 'b': > do_a_or_b(); > } No!!! I LIKE being able to do the following: void some_func(void) { while(1) { /* because people don't seem to like for(;;) */ /* something to get a key - that's machine specific */ switch (key) { case '1': action_1(); break; case '2': action_2(); break; case 'q': return; default: putc('\007'); /* BEEP */ continue; /* SKIP the stuff after the swicth */ } /* now, do some things to be done ONLY if a selection was made, like redrawing the menu after a function has been performed */ } } ----------------- Jeffrey Hutzelman America Online: JeffreyH11 Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu >> Apple // Forever!!! <<
volpe@underdog.crd.ge.com (Christopher R Volpe) (09/29/90)
In article <4b0hPyW00Vp8M7qVd1@andrew.cmu.edu>, jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) writes: |>volpe@underdog.crd.ge.com (Christopher R Volpe) writes |> |> |>> Ok, how about requiring the programmer to make it explicit when |>> he/shewants it to fall through, rather than making that the default? |>> Like so: |>> |>>switch(ch) |>> { |>> case 'a': |>> do_a(); |>> continue; |>> case 'b': |>> do_a_or_b(); |>> } |> |>No!!! I LIKE being able to do the following: [deleted example using continue statement] Sorry, I didn't mean to overload that keyword. I should have suggested a new keyword, although I can't think of a good one right now... ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
ravim@gtenmc.UUCP (Ravi K Mandava ( Vox Populi )) (10/02/90)
In article <12252@crdgw1.crd.ge.com> volpe@underdog.crd.ge.com (Christopher R Volpe) writes: >In article <4b0hPyW00Vp8M7qVd1@andrew.cmu.edu>, jh4o+@andrew.cmu.edu >(Jeffrey T. Hutzelman) writes: >|>volpe@underdog.crd.ge.com (Christopher R Volpe) writes >|> >|>> Ok, how about requiring the programmer to make it explicit when >|>> he/shewants it to fall through, rather than making that the default? >|>> Like so: >|>> >|>>switch(ch) >|>> { >|>> case 'a': >|>> do_a(); >|>> continue; >|>> case 'b': >|>> do_a_or_b(); >|>> } >|> >|>No!!! I LIKE being able to do the following: >[deleted example using continue statement] > >Sorry, I didn't mean to overload that keyword. I should have suggested >a new keyword, although I can't think of a good one right now... > >================== >Chris Volpe How about 'proceed'? To solve the original problem (or sin, whatever) (i.e. to be able to break out of a switch statement within a 'for' or 'while' loop), why not change the 'break' statement to take an argument (like the 'return' statement does) that denotes the number of loops (including switch body) that you would like to get out of? (If my memory serves me right, this syntax [ break n - n is no of loops default being 1 ] is implemented in 'sh' and 'ksh' languages.) IMHO, this has some advantages like (a) you can still use the old syntax (like having to use 'break' in each 'case' body thus allowing 'fall through' wherever it is useful and having the ability to break out of the innermost 'for' or 'while' loop) (b) you can break out of any number of loops thus eliminating the need of using flags The same syntax can be extented to the 'continue' statement as well. - Ravi Mandava
jeenglis@alcor.usc.edu (Joe English Muffin) (10/02/90)
ravim@gtenmc.UUCP (Ravi K Mandava ( Vox Populi )) writes: >To solve the original problem (or sin, whatever) (i.e. to be able to break >out of a switch statement within a 'for' or 'while' loop), why not change >the 'break' statement to take an argument (like the 'return' statement does) >that denotes the number of loops (including switch body) that you would >like to get out of? Or, you could just use a (GASP!) goto. 'break n;' means the reader has to count the enclosing loops; this would probably be painful for n >= 3 or so. Under the assumption that a symbolic name is better than a number, a well-placed goto is probably "more structured" than a multi-level break. >IMHO, this has some advantages like > (a) you can still use the old syntax (like having to use 'break' > in each 'case' body thus allowing 'fall through' wherever it > is useful and having the ability to break out of the innermost > 'for' or 'while' loop) Ditto goto. > (b) you can break out of any number of loops thus eliminating > the need of using flags Ditto goto. >The same syntax can be extented to the 'continue' statement as well. Hmm... Has anyone started a "Frequently Proposed Ways to Futz With C" list? Preferably with a list of reasons why it shouldn't be changed? --Joe English jeenglis@alcor.usc.edu
Sm@cerberus.bhpese.oz.au (Scott Merrilees) (10/02/90)
volpe@underdog.crd.ge.com (Christopher R Volpe) writes: >How about combining the "let's make break implicit" idea with the >"lets add ranges and lists" idea and solve everybody's problems? E.g.: >ch = getch(); >switch (ch) { > case 'q','Q',27,13: > exit_menu=1; > case 'a': > do_a(); > ...etc >} >Now, a break within a case can be used to break out of an enclosing loop, >and the "multi-case" capability is still maintained. I still want to be able to do: switch ( var ) { case '1': func1(); case '2': func2(); default: func3(); break; } Sm -- Scott Merrilees, BHP Rod & Bar Products Division, Newcastle, Australia INTERNET: Sm@bhpese.oz.au UUCP: ...!uunet!bhpese.oz!Sm
davidsen@antarctica.crd.GE.COM (william E Davidsen) (10/02/90)
In article <12180@crdgw1.crd.ge.com>, volpe@underdog.crd.ge.com (Christopher R Volpe) writes: |> How about combining the "let's make break implicit" idea with the |> "lets add ranges and lists" idea and solve everybody's problems? E.g.: |> Ranges were discussed by X3J11, but not added to the language. Pity. All this doesn't solve the problem that it is a lot easier to use break to get out of a switch than to use goto's to simulate fallthrough. Look at some existing code and see what it would look like changed. Once upon a time there was a language called FLECS, which compiled into FORTRAN. We modified it locally in a number of way, including two forms of case statement, one of which fell through and one which didn't. Another construct which looks like a switch but doesn't fall through would be a way to solve this without breaking old programs. That doesn't mean I think we need it. I really did like the endcase statement, from the standpoint of not overloading the use and meaning of break. Then again, people who ever used BCPL are getting fewer and harder to find.
mcdaniel@adi.com (Tim McDaniel) (10/03/90)
Note that this newsgroup is comp.lang.c, not comp.lang.some.future.
language.that.resembles.c. Such discussion is fun or useful, but it
doesn't really belong here.
Sm@cerberus.bhpese.oz.au (Scott Merrilees) "still want[s] to be able
to do" fallthrough in "switch" alternatives. In some hypthetical
language D, one could always use "goto" to branch from one to the
next. IMHO, I don't think that fallthrough occurs so often that this
workaround would be needed much.
--
Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Work phone: +313 973 1300 Home phone: +313 677 4386
Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdanielgoudreau@dg-rtp.dg.com (Bob Goudreau) (10/04/90)
In article <MCDANIEL.90Oct2143223@dolphin.adi.com>, mcdaniel@adi.com (Tim McDaniel) writes: > > Note that this newsgroup is comp.lang.c, not comp.lang.some.future. > language.that.resembles.c. Such discussion is fun or useful, but it > doesn't really belong here. Agreed. I suggest redirection of this thread to alt.lang.cfutures. > Tim McDaniel > Work phone: +313 973 1300 BTW, this is not a valid telephone number. There is no country code 313, nor can there be since the Netherlands has +31. You live in the North American Numbering Plan (country code 1), so presumably you mean to say +1 313 973 1300. ---------------------------------------------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau USA