Dear DDJ,
I read with great interest Allen Holub's article on C compilers in the October 1987 issue, in particular the comparison between Turbo C and Quick C. I largely agreed with his point of view about the programming environments, which I have little use for--they get in the way and are an additional source of compiler bugs. On other points, however, I disagree.
I finally received my Microsoft C 5.0 upgrade from 4.0 yesterday (December 4). Allen's complaints about the delays in delivery of Turbo C seem ironic to me, given the even longer delays in shipping Microsoft C and Quick C.
Allen's tests of the compilers must have been incomplete because he rates Quick C as clearly superior to Turbo C. There are several respects in which Turbo C 1.0 is superior to Quick C 1.0, and Turbo C increases its lead with Version 1.5.
First, Turbo C's documentation is much better. Second, Turbo C compiles 35 percent faster when you use Quick C's optimization switch. Third, even with Quick C's optimization turned on, executables produced by Turbo C run 15 percent faster than those generated by Quick C using my generic math function and numerical benchmark (PC Tech Journal, January 1988).
Fourth, and by far the worst, there is a serious bug in Quick C's numerical library: sines and tangents are apparently computed only to float accuracy, even when all real functions and variables are declared double. Alone of seven PC C compilers I have tested, Quick C fails my double-precision accuracy diagnostic on these functions. Quick C's debugging facilities are superior to the nonexistent ones for Turbo C 1.0, but Borland says it will rectity this situation "soon."
The only reason I can see for using Quick C is to migrate easily to Microsoft C 5.0. Even so, nonoptimized compilation for Quick C takes almost 50 percent of that for Microsoft C 5.0. This doesn't seem worth it to me because Quick C doesn't produce the same numbers as Microsoft C 5.0.
Users of these compilers should be warned that optimization with Quick C does not change the numerical results (though it does markedly slow compilation), but iterative multiplications and divisions produce slightly different results with Microsoft C 5.0 when you optimize the loops.
Jim Roberts
3605 Centinela Ave., #2
Los Angeles, CA 90066
Allen replies:
I disagree.
First, release dates. There are two points:
- 1. Borland wouldn't give me a prerelease version of Turbo C. It gave a dog and pony show down in Scotts Valley but wouldn't give me a copy of the compiler to work with at home. I'm not willing to review a product that I can't work with on a day-to-day basis, and because I had a beta version of Quick C, I felt competent to talk about it, even though it hadn't been released at that time.
- 2. I agree, that neither company should have advertised their products as finished until they were. The problem here is projected release dates vs. advertising deadlines. You have to place an ad several months in advance of its publication, and it is usually impossible to guess accurately when a real product will be finished. I think that both Microsoft and Borland jumped the gun, however.
Second, by my standards Turbo C's documentation is inferior to Quick C's. The two users' guides are comparable, but Turbo C's library documentation is miserable. It's poorly organized and formatted; the programming examples--if they're there at all--are trivial; and obscure and nonstandard subroutines are often documented (and I use the word loosely) in only two or three sentences. I use the run-time library documentation for my compiler on a daily basis; I read the users' guide once when I get the compiler. Consequently, the quality of the former is much more important, and Turbo C falls down in that department.
Next, I'm not sure about the comparative compile times with the newest Turbo C version. I haven't seen a copy. As I sald in the review, I was using Turbo C 1.0 and a beta version of Quick C, so it's likely that things have changed. Mr. Roberts and I are testing the compilers in radically different ways, however. My benchmarks were two very large programs (versions of the Unix lex and yacc utilities) that used virtually no numeric computations but did a lot of data manipulation, especially at the bit level. Mr. Roberts seems to be compiling smaller, numeric-intensive programs.
Because I disliked both of the interactive environments, I compiled with the command-line versions of both compilers, the compile process driven from a make file. I did find that it took longer to load Quick C than it did to load Turbo C. In fact, on a short program, it often took more time to load Quick C than to run it. Because I was compiling relatively large modules, however, the load time was insignificant when measured against total compile time.
Compile time is relatively insignificant in the greater scheme of things, however. If I save five hours with a good debugger but waste an hour with longer compile times, I'm still four hours ahead. Quick C's debugging facilities are indeed superior to the nonexistent ones for Turbo C, and the debugger alone makes Quick C a considerably more useful compiler, especially if you're just learning the language. Borland seems to be fostering rumors that it's working on a debugger, but the last time I talked to the people at the company, they wouldn't even commit to the fact that a debugger was in progress, much less give me a projected release date. It may be available "soon," but are they talking geologic time or historical time?
Other problems are reliability and portability. My Turbo C-compiled benchmark didn't run initially because of bugs in and omissions from the I/O library. There was no signal() function, getenv() didn't work properly (it returned a PATH environment when I had asked for a PA environment but had set PATH first), and so forth.
Of course, by the time you read this letter, things may have changed: Borland may have fixed the documentation, improved the library, and come out with a debugger to match dbx on a Sun workstation. But I'm only willing to discuss products that actually have in my hands. Similarly, I test compilers by working with them rather than by running artificial benchmarks. Consequently, I'm likely to miss a few things that I don't use very much (like the accuracy of a sine function), but I think my methods give a much better feel for how a product works in general than do more formal benchmarks.
Dear DDJ,
We'd like to set the record straight on the shipment of Borland International's Turbo C.
Borland announced shipment of Turbo C and distributed the product on the same day: May 14, 1987. We said we'd ship in the second quarter of 1987, and we made it by over a month and a half.
We'd also like to point out that Borland collected no money before the product began shipping. As a matter of policy, Borland neither cashes checks nor bills credit cards until a product is shipped.
With the volume and depth of information that Dr. Dobbs' offers, it's hard to check every detail. Thanks for letting us contribute to your fine publication.
Borland International
The editor replies:
It was never our intention to imply that the folks at Borland were committing mail fraud, or anything of the sort. Borland has generally performed very well in customer relations.
It was incongruous, however, to have Turbo C arrive at our offices with a note from Philippe Kahn proclaiming the product was shipping "right on time"--three months after the first ads had appeared in magazines. To claim that an advertisement with a snip-out coupon and an 800 number for credit card orders isn't an official product announcement is mere sophistry; ads are designed with coupons and credit card phone numbers to generate an immediate response. Our readers had every reason to expect shipment within 30 days of the first ad.
In short, if Borland had originally planned to ship Turbo C in the second quarter it would have been more honest to either postpone the ad a few months or include a disclaimer ("please allow 3 to 4 months for shipment").
Corrections
Dear DDJ,
Readers, your response to "An Extended IBM PC COM Port Driver" in the June 1987 issue of DDJ was gratifying. The version of excom.asm available from DDJ on diskette seems to be working, whereas exmode.c has a serious bug. Exmode will work correctly if you have two COM ports and will not do anything right if you only have one port. Specifically, in one-port systems exmode will always respond with "excom not installed" and fail to execute your commands. To correct this, change the && in the first if statement of main to ü. In addition, some early versions of exmode used remove as a function name. This conflicts with some libraries and can be corrected by renaming the function. How embarrassing, sorry 'bout that.
Tom Zimniewicz
Lima, NY 14485