datanguay@watmath.waterloo.edu (David Adrien Tanguay) (10/07/89)
In article <4467@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
<Switch provides a method of conditionally splitting the flow-graph,
<but there doesn't exist a dual of it that would describe the joining of
<some subset of the split branches of the flow-graph.
<
<Something like
<
< switch(fc) {
< case 'c': stuff under c; break;
< case 's': stuff under s; break;
< ...
< case 'u': stuff under u; break;
<
< cases 'd', 'o', 'x', 'u': stuff for doxu cases; break;
< cases 'd', 'c', 'u': stuff for dcu cases; break;
< }
A friend of mine kicked this idea around a few ago when he was
designing a language (Andrew Wright, ForceTwo). You can also have
cases like "anything except 'a', 'b' 'c'", "anything", and "default - i.e.,
anything that isn't explicitly mentioned elsewhere". This kind of flow of
control construct can do some neat things, but it can also lead to
hard to follow code and strange bugs (no "multiple case in switch" errors).
It shouldn't be that hard for the compiler to generate good code for it.
Unfortunately, I don't think it's useful enough to warrant the extra
language complexity. Multiple (sequential) switches would probably mimic
most of the functionality, anyway. Still, it would be fun to play with.
David Tanguayjackson@jabberwock.shs.ohio-state.edu (Michel Jackson) (10/09/89)
Press, Flannery, Teukolsky, & Vetterling remark, in their very useful
book _Numerical Recipes: The Art of Scientific Computing_
Every programming language has some number of "goodies" that the
designer just couldn't resist throwing in ... In FORTRAN we consider the
ill-advised control structures to be
-assigned GOTO and ASSIGN statements
- computed GOTO statement
- arithmetic IF statemetn
In Pascal an example is
-CASE ... OF
In the companion volume, _Numerical Recipes in C_ (yes, i have & use
both ...), they remark
In C, the most dubious control structure is the switch...case...default
construction, recognizable to FORTRAN programmers as a kind of elaborate
"computed goto". Not only is the structure a confusing one, with a
bizarre "drop through" feature, it is also burdened with uncertainty,
from compiler to compiler, about what data types are allowed in its
control expression. It can virtually always be easily replaced by a
more recognizable and translatable if ...else construction. (p.13)
I generally agree with them. Some of the most confusing code I have
ever written relied on (long) switch statements and various drop
throughs (exhaustive testing of a function that had some 8-10
arguments & needed to be demonstrated correct & also had to be shown
to handle various combinations of incorrect inputs properly) ... i
eventually gave up trying to debug my own code & rewrote it from scratch
with a pile of if's. Surely adding "cases" will make switch statements
even harder to figure out ...
i must admit, though, that "tame" switch statements are a great convenience.
---michel jacksonbagpiper@pnet02.gryphon.com (Michael Hunter) (10/09/89)
jackson@jabberwock.shs.ohio-state.edu (Michel Jackson) writes: >Press, Flannery, Teukolsky, & Vetterling remark, in their very useful >book _Numerical Recipes: The Art of Scientific Computing_ > [stuff about FORTRAN deleted] > > In C, the most dubious control structure is the switch...case...default > construction, recognizable to FORTRAN programmers as a kind of elaborate > "computed goto". Not only is the structure a confusing one, with a > bizarre "drop through" feature, it is also burdened with uncertainty, > from compiler to compiler, about what data types are allowed in its > control expression. It can virtually always be easily replaced by a > more recognizable and translatable if ...else construction. (p.13) > >I generally agree with them. Some of the most confusing code I have This is not meant as a flame, but these guys are the one who state in their intro to the C version of their book that "...we intend that all the programs should work on both mainframe, multi-user computers and on personal computers." and then use a routine to provide arrays with indices between two arbitrary index's by subracting a constant from an integer. I don't usually listen to their comments about programming. I would rather think of their code as a way to generate some numbers to test your own routines and that is usually not worth much as test cases are fairly easy to come by for most of the topics that they cover. Michael UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!bagpiper INET: bagpiper@pnet02.gryphon.com
scott@bbxsda.UUCP (Scott Amspoker) (10/09/89)
In article <180@jabberwock.shs.ohio-state.edu> Michel Jackson <jackson@cis.ohio-state.edu> writes: >In the companion volume, _Numerical Recipes in C_ (yes, i have & use >both ...), they remark > > In C, the most dubious control structure is the switch...case...default > construction, recognizable to FORTRAN programmers as a kind of elaborate > "computed goto". Not only is the structure a confusing one, with a > bizarre "drop through" feature, it is also burdened with uncertainty, > from compiler to compiler, about what data types are allowed in its > control expression. It can virtually always be easily replaced by a > more recognizable and translatable if ...else construction. (p.13) This was the point when reading "Numerical Recipies in C" that I seriously lost faith in the authors of the book. I'm sure their math background is solid but their FORTRAN mentality made for very bad C. There is a BIG difference between a switch statement and multple if-elses. A switch statement is a multi-way branch. A switch statement with more than a trivial number of cases is almost guaranteed to be implemented as a jump table. It is not unusual for us to have switch statements with 50 or more cases. To do the same thing with multiple if-elses would seriously degrade performance as well as obscure the meaning of the code. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/10/89)
In article <20754@gryphon.COM> bagpiper@pnet02.gryphon.com (Michael Hunter) writes: >jackson@jabberwock.shs.ohio-state.edu (Michel Jackson) writes: >> [from Numerical Recipes in C...] >> In C, the most dubious control structure is the switch...case...default >> construction, recognizable to FORTRAN programmers as a kind of elaborate >> "computed goto". Not only is the structure a confusing one, with a >>... >>I generally agree with them. Some of the most confusing code I have >This is not meant as a flame, but these guys are the one who state in their >intro to the C version of their book that "...we intend that all the programs >should work on both mainframe, multi-user computers and on personal >computers." and then use a routine to provide arrays with indices between two >arbitrary index's by subracting a constant from an integer. I don't usually >listen to their comments about programming. I would rather think of their ... Yeah, my sentiments exactly. I take issue with a number of their pronouncements, including the abovementioned hex on "case." They also say ... "We like to keep code compact, avoiding unnecessary spaces unless they add immediate clarity. We usually don't put space around the assignment operator '='. Through a quirk of history, however ... That is why you will see us write y= -10.0; or y=(-10.0);, and y=*a; or y=(*a);." I guess they think that extra whitespace compiles into their object or something. I hope they run into "x/*y" some day. Similarly: "We have the same viewpoint regarding unnecessary parentheses. You can't write (or read) C effectively unless you memorize its operator precedence and associativity rules. Please study the table immediately above while you brush your teeth every night." Perhaps they have never heard that parentheses can be used to clarify the meanings of expressions for human readers as well as the compiler. Or that a language with 15 levels of operator precedence (which even K&R admit is confusing), some of which is WEIRD ('>>' lower than '/'? Huh?), might better be written with a few extra parentheses anyway. Then: "We never use the register storage class specified. Good optimizing compilers are quite sophisticated in making their own decisions about what to keep in registers, and the best choices are sometimes rather counter-intuitive." This is true, but on the other hand there is a pronounced shortage of "good optimizing compilers" on non-Ultrix, non-VMS platforms. For a group of authors who are so concerned about "portability" that they eschew the "switch/case" construction, this shows remarkable insensitivity to the needs of the many users of PCs and specialized platforms (cross-compilers, etc.). Last, but not least, a number of their routines require 1-based arrays, which they suggest you pass 0-based array arguments to in the totally non-intuitive manner: f(zero_based_array - 1) -- as if this were an appropriate solution. It is not. The appropriate solution is to recommend strongly that users AVOID MIXING 0-based and 1-based arrays in their applications (we have had bad experiences with this). Furthermore, they never address the tricky issues associated with dynamic allocation in large systems. (Should you keep track of the size of your arrays? How should you allocate them? When should you free them? How long does it take to allocate and free? Is fragmentation a problem?) They merely laud dope vectors, and pass on. "Numerical Recipes in C" provides an excellent source of simple canned numerical methods in C, and simultaneously provides some of the worst C programming advice that I have seen. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/10/89)
In article <4148@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: > >This is true, but on the other hand there is a pronounced shortage of "good >optimizing compilers" on non-Ultrix, non-VMS platforms. For a group of ^^^^^^ Before the dozens of corrections and UNIX-chauvanist rantings come pouring out at me, let me state, YES, this is a TYPO, and I meant to say non-UNIX, non-VMS platforms ... Thanks for your kindness in not berating my Freudian slip. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.