Do we get our money back for the repeated article on circular lists? Or is this a readership-attention-span-survey stunt?

Regards,

John Wheater
Surrey, England

You mean we didn't double your pleasure, double your fun?

Seriously, we have received several such letters, and would like to say thank you all for the kindly pokes at our snafu. We promise to remove all the egg we are wearing because of it, so that we are more recognizable in the future. — dt

Dear Mr. Plauger:

You mentioned in The C Users Journal (October 1991) that you have the Turbo C++ function library but since it is a licensed product you would not pass it on or encourage anyone else to do so! I develop and market a C++ class library with source and I am so glad when one of the most influential person of the C/C++ community shows its support for honest practices. Thanks a thousand times.

Patrick Nicolas
Network Integrated Services, Inc.
221 West Dyer Road
Santa Ana, CA 92707-3426

I'm not completely altruistic. I've earned most of my money selling software that is easily pirated. I am counting on a certain amount of income from selling copies of the code from The Standard C Library. Still, I like to think that I'd encourage honesty even without a personal stake in the matter. — pjp

Dear Mr. Ward:

Listing 2 in your article "Debugging Instrumentation Wrappers for Heap Functions" (CUJ, October 1991) caught my eye. I've had very similar problems regarding arithmetic on void pointers, indeed with any sort of manipulations using void pointers. One experience in particular dealt with the user-supplied comparison function expected by qsort, which takes two (void *) pointers as arguments.

I needed a comparison between two struct objects. My solution was a kludge fix very similar to yours — I defined two automatic pointer variables of the type I needed in the comparison function for qsort My compiler (Turbo C++) wouldn't allow me to do the comparison using the (void *) arguments to the comparison function directly, even with casting to (struct type *). I had to assign both arguments to the new pointers, then use them to do the comparison. Using something like strcmp as the comparison function, in contrast, presents no problem because strcmp takes two (void *) arguments in the first place.

When studying your Listing 2, a solution to the kludge struck me. Simply redefine your my_free function and its redirection macro as

void my_free( char * tree )
#define free(x) my_free( (char *) x ),

I wouldn't be surprised if you've already thought of this one. Thanks for a great article, which indirectly helped to cast (pun not really intended) some light on my problem with . I'm not aware of any previous discussions in CUJ regarding this.

Sincerely,

Tom Nelson
5004 W. Mt. Hope Rd.
Lansing, MI 48917

Call it a kludge if you will. That's the sort of thing that X3J11 expected programmers to do when it changed the declaration of the comparison function for qsort. Honesty in type checking sometimes has its price. — pjp

Thanks for the feedback. I'm glad you found it useful. — rlw

Dear Sir:

With reference to your call for papers on Numerical Applications, I would like to suggest two topics on which I have been working.

In view of your inability to fill orders for your new book on the C library, articles which follow on those topics should prove interesting to your readers. I have followed up on the criticisms which I made of the sin and exp functions which appeared in CUJ, and found in fact that I was able to use the ideas published while fixing the deficiencies and get results better than I have seen elsewhere. I ordered the book and disk when they were first advertised. I spoke to your book department today and they say it will be more months before the book becomes available but they will try to ship the disk alone. In this case I propose to go through the math functions and show where they can be improved, and also where a slight variation on the code will improve performance without affecting accuracy on pipelined processors. I expect to have an HP720 available soon, in addition to SPARC, VAX, and 68000 available now.

In line with Ron Irvine's letter, I could write an article on how to specialize C so that standard compilers generate as efficient code as would be obtained by a FORTRAN compiler. This involves some uses of the const keyword which are mainly theoretical, as current compilers don't seem to be using it for optimization, as well as situations in which making a local copy of an argument which is accessed through a pointer will enable a compiler to perform the same optimizations which would be possible in FORTRAN. For recognition of common subexpressions, the same rules now are followed by several compilers, including gcc, Sun4, and IBM RS6000, so useful recommendations can be made to permit this optimization.

Sincerely yours,

Dr. Timothy C. Prince
452 Palmitas St
Solana Beach CA 92075-2046

Dr. Prince is one of the people I cited in The Standard C Library who demonstrably know more about math functions than I do. He has sent me several errata and suggestions for improvement, for which I am deeply grateful. I'm sure that CUJ will be publishing more articles where Dr. Prince illuminates the murkier corners of computer math.

By the way, I believe that books and code disks are going out the door smoothly now. — pjp

Just for the record... We didn't publish the book. The delays have been the result of our difficulty in getting timely shipments from the publisher. — rlw

Dear Sir:

With reference to Ron Irvine's letter, I have written an article on the technical merits of C vs FORTRAN, but I don't know whether it will be published. It went out on Usenet in an earlier version, but I haven't found a way to access the net since I moved. This article expects the reader to be as familiar with FORTRAN as with C, and turned out to be fairly long. To summarize, the only situation of which I am aware in which ANSI C does not have the potential to equal the performance of FORTRAN is where a function has two or more in-out arguments.

FORTRAN compilers can be implemented quite successfully by automatic translation to C, but the code required is not always a style which is natural to use in C. I have encountered codes which were written in FORTRAN with no intent of translation to C, which run faster when certain subroutines are translated automatically to C and compiled with gcc than when they are complied with a FORTRAN complier on a SPARC, because of gcc's better behavior when faced with a shortage of pointer registers. If programs were coded in C without using (intentionally or not) the full generality of the language, current compilers could generate equally fast code in C or FORTRAN. This is assuming that programmers and compilers take full advantage of ANSI C, including use of features such as the const qualifier; otherwise much C code cannot be optimized on a modular basis.

The other side of this answer is that the C programmer needs more knowledge than the FORTRAN programmer, to avoid errors which FORTRAN does not permit, as well as to write optimizable code.

Sincerely yours,

Dr. Timothy C. Prince
452 Palmitas St.
Solana Beach, CA 92075-2046

C is often better than FORTRAN, but sometimes it is irretrievably worse. Both Cray Research and the Numerical C Extensions Group have educated me at length on this topic. Writers of Standard C compilers must catch up with three decades of determined numerical optimization in FORTRAN compilers. And C lets you do far more with pointers than FORTRAN permits with subscripts. Some optimizations are just not safe in C, at least not without additional semantic hints.

Dr. Prince is again correct, however. The vast majority of FORTRAN programs (and programmers) would be better off in C. You must keep the numerical savvy of the FORTRAN community and adopt the coding style of C to profit completely from the transition. — pjp

Dear Mr. Plauger:

I would like to present my own response to Ron Irvine, who asked (CUJ, November 1991) why FORTRAN is the preferred language for numerical applications.

I am a multi-language programmer, and one-half of a team who currently writes and maintains a scientific analysis library in both C and FORTRAN. This library is compiled across many platforms (Vax, PC, MacIntosh, etc.). My great age and experience force me to speak out.

I began serious scientific programming in FORTRAN in 1963, when I was asked to provide the surface temperature of Mars at the positions and times where the radio signal from a space probe grazed its surface during an occultation. Since that time I have programmed in many languages, and even taught a little programming to my undergraduate physics students.

The power of FORTRAN lies in the numerous, robust mathematical function libraries intrinsic to all FORTRAN compilers. The limitations of FORTRAN are string handling and I/O.

C will do scientific analysis as fast as FORTRAN. I have written the same scientific program in both languages. When compiled, you can't tell which is which. In FORTRAN, I struggle with string handling and I/O. In C, I struggle with data type conversion, and additionally must test for underflow, etc.

"The tremendous power of C pointers" is part of the litany of C-chauvinism. I remind you that FORTRAN has always had pointers. Unfortunately, in the beginning (and I was there), it had nothing else. Everything was passed by pointer! C pointers have nothing to do with the issue. The issue is: FORTRAN intrinsic mathematical functions are more complete and more robust. Historically, scientific programmers began on mainframes without C compilers, and of necessity, have pushed the art of numerical programming further.

I appreciate your efforts to bring C mathematical routines up to snuff. But your quest for "acceptance of C by the FORTRAN old guard"? I know the old guard. When C has enough intrinsic functions with the flexibility and stability of the FORTRAN functions, you could feed it to him, but only if you rename it FORTRAN.

Very truly yours,

Lin DeNoyer
Spectrumm Square Associates
755 Snyder Hill
Ithaca, NY 14850

I too began programming Physics applications in FORTRAN back in 1963. I think you speak well for a significant fraction of the Old Guard, of which I was once a member. Those existing libraries are certainly important. So too are the millions of lines of existing FORTRAN applications. All that code can in principle be translated mechanically to Standard C. That should preserve its flexibility and stability.

The price you pay sometimes is inferior performance. But that's not because you access arguments via pointers, as you rightly point out. At least not directly. The problem is that a C compiler can't optimize accesses via argument pointers nearly as aggressively as can a FORTRAN compiler. You have to watch what you do with a C pointer because you don't know where it's been. C permits all sorts of aliasing with pointers that is forbidden in simpler languages such as FORTRAN.

Your final remark is the most telling. Many FORTRAN programmers will not switch to C simply out of habit. The new language is not sufficiently better, to them at least, for an old dog to want to learn new tricks. I can sympathize with that viewpoint. I feel the same way about C++ sometimes. — pjp

Dear Editor:

Your magazine has always been helpful to me as a programmer, and perhaps you or one of your readers may be able to help me locate an algorithm to send voice through the IBM-PC's speaker.

A common way to reproduce voice is to feed the AM signal into an 8-bit A to D converter, which is then sampled and the values stored in sequential order. To "play back" the values are sent to a D to A converter which reproduces the voice accurately enough to recognize a person's voice.

Unfortunately, the PC's speaker is driven by digital logic circuitry and current is either on or off in the speaker coil. It is impossible, therefore, to send an AM signal to the PC's speaker. However, one can send a constant amplitude, variable width pulse train. The algorithm I need is: how does one convert a string of 8-bit numbers representing an AM signal into a list of number representing the variable width string of pulses the PC's speaker needs, with minimal loss of information?

From what I have been able to gather, the AM waveform needs some high pass filtering and then is sent through a differentiator. The output should be a logical 0 if the differentiator's output is positive and 1 if negative. While it is easy to see how one could build such a system in hardware, I want to do it with software. Using the 8-bit code representing the AM information as input, how does one get the "differentiated" output? The speech type program found in shareware sources have not been of much help. Can someone point me in the right direction?

Sincerely,

Theron Wierenga
P.O. Box 595
Muskegon, MI 49443

I haven't fiddled enough with digital filtering to be much help here. Anybody? — pjp

See "Writing for the PC Speaker" by Robert Bybee in Windows/DOS Developer's Journal, December, 1991. Call our Customer Relations department for back issues and reprints. — dt

Ladies and Gentlemen:

I wanted to comment on a couple of things I have noted in the past few months in letters to the magazine. First, I would really hate to see your source code distribution system handled through CompuServe. Rather than bore you with gory details, I'll just say that I once subscribed to CompuServe. While I agree that the current system has its drawbacks, I believe it is infinitely preferable to CompuServe.

Concerning the letters from those seeking the path to enlightenment (i.e., learning C): the best thing I ever did was read a good book on compiler construction. I first read K&R, and achieved a certain amount of literacy in the language (I wrote programs that worked), but many times I wasn't sure just why things worked. In C, a language on intimate terms with its supporting hardware, such ignorance is cumbersome at best and dangerous at worst. However, I bought a used copy of Aho & Weinberger, and suddenly the "incantations" took on new clarity. My approach to pointers had always been just above the level of mysticism, but after learning how a compiler would generate code to declare a pointer, the mystery was gone. Studying compiler construction might seem like a big bite for a beginner, but I think that after one has achieved technical facility with the language, it's not too large a step. It helped me a lot more than any "teach yourself C" book I ever saw.

Lastly, I wish to toss in my opinion regarding the C/C++ controversy, i.e., whether you should lean more toward C++. I have a C++ compiler (Borland C++), I have read a number of books and articles on it, and I have had the opportunity to discuss C++ at length with a friend who recently took a course in it at the University of Washington. While I can envision reasons why someone would wish to use C++, those reasons do not apply to me — nor, I believe, to a large number of programmers and designers. C++ seems to be more an idiom than anything else (that from my friend), and as has been stated in articles in CUJ, it is not the only way in which to obtain source code reusability. Further, I for one am not convinced that "object oriented programming" is the be-all and end-all which many of its proponents seem to claim. To my (possibly ignorant) way of thinking, C++ is a new flavor, not a new food.

Having said all that, I would like to see you remain a magazine devoted to C programming. If you do ever decide to become The C++ Users Journal, I will probably find another magazine which addresses my favorite language as well as you do now. I like C. It works for me.

Finally, regarding that guy who responded to my earlier letter in which I requested a nude centerfold: I guess some people have nothing better to do than to pick at nits. Can we code him a sense of humor in C, or would it take C++?

Very truly yours,

Ian S. King 520
SW Yamhill Street #430
Portland, OR 97204

I too learn languages best by seeing how they are implemented. I'm not sure that approach works for everybody, but if it works for you too, go for it. As for C++, it seems that sanity is beginning to prevail. More and more people are finding good uses for C++ and other OO languages, but the religious zeal of the newly converted is dying out.

I can think of several clever remarks about nude centerfolds, the need for a sense of humor, and the relative merits of C vs. C++ in this context. Robert will probably be happier if I print none of them here. — pjp

Maybe so, but I'm glad I got to read King's remark — rlw

Dear Mr. Plauger,

I have a question that I was hoping you might be able to help with. I'm using VAX C with the curses library running on a VAX3100, I've created a selection menu, using curses, to execute other programs.

The problem I'm having is, the getch function, available with the curses library, doesn't send the character you enter until you've also hit return. On an IBM PC, getch will get a single character from the keyboard, and send it to your program without having to hit the return key.

Is there another way of doing this, on the VAX using C, without having to call other language routines? There is a function available in VAX Basic called INKEY which looks like "INKEY$ (0%, WAIT)". There is also SMG$ routines available on the VAX to get unsolicited keyboard input, but if I user either, porting to other systems will be a pain.

Sincerely,

James Cook
13213-66B Ave.
Surrey, B.C.
V3W-8P4

The issue you face is common to many systems, not just VMS. (If you haven't hit it on the PC, you've just been lucky — after a fashion.) The problem is that most of the time you want keyboard input to be "cooked" a line at a time. You want the typist to backspace over typos, even retype the whole line, until it is correct. That means the input cooker must wait until the typist strikes the return key before the program can see the first character on a line.

Nearly every system I've ever encountered has some way to request "raw" input. The program gets each character as it's typed, with no line editing performed. Sounds like your PC getch gives raw input whether you ask or not, for good or for ill. The problem is, no standard way exists to specify raw input in C.

Your best bet is to write your code in terms of a function with a name such as getraw. You'll have to tailor the function for each system, but at least it hides the irregularity. — pjp

Dear Mr. Plauger:

I enjoyed reading Mr. Rothkin's article entitled "PC UART Device Driver" in the December 1991 issue of The C Users Journal. I have been programming the serial port for over eight years and have developed my own routines which will be modified based on information from this article. One thing he mentioned in his article that he says would be difficult to handle would be the proper handling of IRQs nine through fifteen. One method I have used is to have two entry points to the same routine, one for one interrupt vector, and a second for the other interrupt vector. You simply indicate which entry point was used and proceed from there. Then, when the interrupt routine has completed, it can check to see which entry point was used and respond to the appropriate 8259 interrupt controller. Of course there are other ways to handle the situation, but this has been the way I have chosen for my device drivers.

Thank you for this and other articles and keep up the good work.

Very Truly Yours,

Peter R. Vermilye
The Programmers' Guild, Inc.
1833 New Riverdale Rd.
Germantown, TN 38138

Thanks. — pjp

Dear Sirs;

I need your help! I use Borland C++ for a compiler, Btrieve or Paradox engine for a RDBMS, but I don't have any interface tools. I am searching for a C and/or C++ user interface package. I would like something that is comprehensive, yet easy to use. I want it to have a WYSIWYG designer for menus/screens/forms and to generate program stubs (option).

I have demos of Greenleafs DataWindows, Island System's graphicsMenu, Softway's Hi-Screen Pro II, and Vermont Creative Software's Vermont Views with designer. These packages represent the price range I am working with. Running the demos only confuses me more; I like features in each.

Do you have any recommendations for a C programmer looking to give his programs a quality interface? I will appreciate any advice you can give me. Thank you.

Sincerely,

Jeffrey S. Dreke
15709 North Lund Road
Eden Prairie, MN 55346-1550

Sorry, that's another area (of many) where I'm weak. Anybody? — pjp