Dear DDJ,
In the November 1987 "Running Ught," you asked whether it was sensible to print source code listings. I think it is definitely a good policy for three reasons: some, like me, have no other access to listings; studying the printed listings is helpful in understanding a program; and those who peruse DDJ away from a telephone would appreciate printed listings.
You mustn't assume that everyone has ready access to a fast modem or has the money to buy one; I have limited resources and cannot afford a modem. Studying the printed listings is useful in understanding a program and its accompanying article. It would be maddening to read in the text "see line 97" without the listing at hand, especially if you're in a library. Finally, those who flip through DDJ in bookstores may decide to buy based on the listings. I have. In fact, I bought several issues at full retail before subscribing. So please don't stop printing source code listings in DDJ--they're most useful.
Dan Velting
Grand Rapids, Ml 49506
Dear DDJ,
November 1987's Running Light provided a long overdue relief. Is it true, you are really going to spare me the monthly trip to my not-so-local newsagent? My sole reason for going there is to pick up a certain computer magazine featuring full-length source listings. If said magazine stops publishing those listings, I in turn shall stay home near the warm oven, which comes in handy with winter almost upon us.
Were I mad enough to use the twisted pair to download the source code absent from DDJ's pages, the post office would charge me $8.40/ minute for a phone call to the U.S. If the rare occasion should indeed find me in a spending mood, it would still be in vain, as your Bell standard modem finds itself unable to talk to my V21/V22/V23 DCE.
No, if you want me to keep on getting cold and wet feet, you will continue to print listings in DDJ. But who could be that cruel?
Andreas Burmester
2000 Hamburg 70
West Germany
Dear DDJ,
Keep the listings! Not all of us have sold our souls to IBM and MS-DOS. Not all of us live where CompuServe is a local call or can afford the charges. Not all of us have a 2,400-bps modem.
The listings are the foundation of DDJ. How do you read an article about a program without access to the code? If you do away with the listings, you'll be just another Byte--bland pap for computer illiterates.
Mad at you for even suggesting such a thing.
Donald Lashomb
Cranberry Lake, NY
Editor's note: A brief storm of controversy blew up on Compuserve following Allen Holub's comments on C compilers in his October 1987 "C Chest" column. A sample from the thread follows:
Sb: C reviews 10/87
Fm: Jeff Brenton 76703,1065 To: Allen Holub 72407,3564
Dear Allen,
Is Turbo C a better product than Quick C? Probably not, but, until mere mortals can purchase and receive Quick C, Turbo is a better product for the "interested in C, but no corporate backing available for my education" user. As I write this note, no one I know of has received Quick C, including people who ordered it directly from Microsoft as part of the version 5.0 upgrade.
On the other hand, Turbo C, though it lacks even a symbolic debugger, has been in my hands since July, and generates better code (for the most part) than v.4.0 of Microsoft C. The fast compile times make it much more "fun" to use than any other compiler I have access to. Its earlier delivery, combined with its performance and low cost, made it possible for Borland to sell more Turbo C packages than Microsoft ever sold of MSC, just in the first months after its release! I wouldn't be surprised if Borland manages to triple Microsoft's C compiler sales before Quick C hits the market.
(Borland's currently estimates Turbo C sales at over 150,000.--Ed.)
In spite of learning C in the old separate-everything environment, I still use Turbo C's integrated environment, since I haven't needed to use inline assembly yet. For the sort of quick and dirty stuff I do, l have grown to accept the clunky editor in exchange for the way it drops me into the editor and shows me "the error of my ways." I still use the DeSmet SEE editor for writing and modilying programs, however.
I also appreciate Borland's intention to deliver a "conforming" ANSI C compiler, as opposed to Microsoft's intention to "implement the important aspects of the proposed ANSI standard.
I will not purchase Quick C by itself; I will wait until I can afford to buy the full Microsoft C v. 5.x package. After all, programming is but a hobby for me at this time, and I don't have a company buying my compilers for me. lf Quick C had been available in June, like Turbo C, I might have bought it instead, but it wasn't, so I bought my first Borland product ever.
Sincerely,
Jeff Brenton
Woodstock, IL
Dear Jeff,
Your points about availability are well taken. Quick C was supposed to be available by now. As for "conforming" to the ANSI standard (or at least conforming as well as possible to what is, after all, a moving target), both compilers are the same. As for conforming to the de facto Unix standard for the non-ANSI functions, Microsoft is far superior to Turbo. There are problems with the Microsoft Unix support (such as no ioctl()) but I'd rather have no function at all than some function that calls itself ioctl() but has no relationship to the Unix function whatever, as is the case with Borland.
Signal is another case in point.
--Allen
Dear Allen,
Your example of ioctl() is a rather poor choice. By definition, such a function must be OS-specific; the version in Turbo provides "a direct interface to the DOS ioctl call,"just as ioctl() provides access to the Unix system call. Sure, it is wonderful to have a function hide the differences, but, since you are already dickering with system-specific code, what good is "portability"?
You call the Draft ANSI Standard for C a moving target, and then point to Microsoft's adoption of the "de facto Unix standard." Which one? Version 7, System III, System V, BSD? If SysV or Berkeley, which release? There are many differences, both major and minor, between the C compilers in these Unix systems! The Unix "standard" doesn't have to move--it is so broad, that you can call virtually any variation on a function's actions "Unix standard".
That was the whole purpose of X3J11-to establish a true standard, one that allowed some leeway. There are a minimum number of functions, headers and macros that must be there to be "conforming," and their use means portability to other complying compilers. Borland says they are shooting for full compliance. Microsoft says "the important parts." But who decides what is important enough to include? With all the fighting that went on over what was in and out of the standard, ANSI must think all of it is important!
I probably will get Quick C and Microsoft C 5.0 eventually. But Turbo C has and will continue to do well for me. Upon its arrival, DeSmet and Eco both left my hard disk. Turbo C takes up less space, generates code better than most, and most of the major bugs have been fixed in my copy.
C you around!
Sb: #Datalight Optimum-C Fm: Dave Searles 73647,1011 To: Allen Holub 72407,3564
Allen...Ijust read your review of Datalight Optimum-C in the October DDJ. I agree with your assessment of the compiler except for one major point. Optimum-C does support debugging as it does produce line number information with the '-g' option. Granted that a Codeviewtype debugger isn't included, but have been very happy with my combination of Optimum-C and Periscope II. I have all the benefits of Microsoft C at less than half the price. And as far as I can tell, I'd put Periscope up against Codeview any day, especially Periscope version III. Nothing beats a resident debugger... It's great when you suddenly notice an anomaly in a previously "debugged" piece of code... just hit the NMI switch and snoop around. Sorry for the sales pitch, but I thought you gave Datalight a cheap shot, even after they have given all of us a cheap shot at a really good compiler.
Fm: Bouce Kitchin 75046,1131
I really take exception to the assumption made by a number of people (usually but not always those who have little or no experience with Turbo C or in one case I remember, a person who used it for a day, ran into a glitch and gave it up and told the world that it was bad) that Borland products are for Sunday hackers. In the DDJ article, it was admitted that Turbo C sometimes generated better code than MSC 4.0 but not as good as MSC 5.0. For the price, I hope that MSC 5.0 generates better code, that has not been MSC's strong point up till now.
Without looking at price, I have found it difficult to see much superior about MSC 4.0 over Turbo C and I have found some ways in which Turbo C is superior (not including its greater conformance to the draft ANSI proposal whichIassume that MSC 5.0 will catch up with, that is just a matter of release dates versus when ANSI updates the draft--a moving target). I've used both compilers with a program that contains many source files with a total line count approaching 20,000. The final code of Turbo C is smaller with both optimizing for space, I've examined a lot of code with both and find a toss up (depends on where you look), and Turbo C gave me better warnings about ambiguous code, about 20 percent of which were latent bugs that I would have had to debug when running.