New super switch, was Re: The final word on GOTO

[Joseph N. Hall]

In article <20754 at gryphon.COM> bagpiper at pnet02.gryphon.com (Michael Hunter) writes:
>jackson at 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 at 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.