Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!brl-adm!seismo!elsie!imsvax!ted From: ted@imsvax.UUCP Newsgroups: comp.sys.ibm.pc Subject: Re: Turbo C Message-ID: <691@imsvax.UUCP> Date: Sun, 22-Feb-87 10:45:07 EST Article-I.D.: imsvax.691 Posted: Sun Feb 22 10:45:07 1987 Date-Received: Mon, 23-Feb-87 02:24:31 EST Organization: IMS Inc, Rockville MD Lines: 180 kent@ncoast of Cleveland Public Access UNIX, Cleveland, OH writes: >My opinion is : don't bother with Turbo C. There are other products out there >that must be just or good (or better), and by all indications, Borland's Turbo >C will share all of the drawbacks of the other Borland Products, to wit: >1. Non-standard (in troubling and non-trivial ways) implementations. Borland >says that Turbo C will adhere to ANSI Standard C, but don't expect it to >be any closer than Microsoft C 4.0. My bet is that it will be as close to >ANSI C as Turbo Pascal is to ISO Pascal. Is this a fatal flaw? Depends on your >point of view. It is definitely fatal in a professional, production >environment. I've used Turbo Pascal in a professional production environment quite a lot. It speeds up the professional production something like 10 to 1 over using the C compilers which are available for PCs. Normally, all things being equal, I would prefer C to any other programming language, however, aside from programs which must be ported to other architectures, I have switched my PC programming almost entirely to Turbo Pascal simply because I view the available C compilers as retarded by comparison. There are a number of reasons: 1. Price: at a retail price of around $70 and a street price of around $55, Turbo Pascal is nearly free. Reasonable DOS C compilers go for around $300 and the only reasonable C INTERPRETER available until now has been going for around $450. Keep this point in mind; compilers and interpreters both have their place in the scheme of things and Turbo products function as both. Few if any other packages make this claim. 2. Turbo Pascal produces very fast code. Further, the compiler itself is almost supernaturally fast, typical 2000 line programs compiling in 15 seconds on 6mh ATs. A CCI Power-6 (rated 10 times VAX 780 compute power) cannot match this with one user on the system. Present DOS C compilers don't come anywhere close to this. 3. Turbo has the only completely believable debugging system in the Micro world. All other debugging systems amongst micros, to my knowledge, involve breakpoints and single stepping. In real life, blowups usually occur on the 876'th pass of some 200 line logical loop; who in hell wants to single step through all of that? The ONLY thing I ever want to know when a program blows up is the line number on which it blew; I figure I'm bright enough to figure out WHY it blew. Turbo not only tells me that, it puts me right on that line in its editor. It is the only realistic and helpful debugging aid I have ever found in the mini-micro world (the ideal being something like the debug feature on the UNIVAC 1100 series 10R1 Fortran, of course). 4. Turbo is a large super-set of standard Pascal, with a tremendously good interface into DOS and PC functionality, things which lie outside of any of the ANSI standards for programming languages. It actually allows machine-coded routines to be imbedded right into Turbo routines (Turbo inline code), allows DOS calls with the use of only one simple register structure, and has easy systems for addressing segments and offsets of Turbo variables, labels etc. Such code can be made as fast as is possible on 80x86 devices. Masm interfaces for the various C compilers are not as clean or elegant. I am assuming Turbo C will also have this feature. 5. Turbo has several good systems for dealing with graphics applications, including the "turtle" system. These capabilities go beyond those of other programming languages available for DOS machines. I assume Turbo C will also have these features as well. 6. Turbo is heavily supported by after-market and free-ware packages and applications. Typical bulletin boards in the DC area will have 20 C-related files on hand, 45 Basic files, and 200 Turbo files. C programmers end up spending an extra $100 or $200 for a new function library every time they turn around. For Turbo, an unbelieveable number of such items are lying around free. Things of this nature which are lying about on the various D.C. area BBS's and from the PC SIG (and which are, hence, free) include: a. A sprite editor and very clean and elegant system for producing animation and cartoon effects using Turbo. b. An assembler which generates accurate Turbo inline code. This is a biggie and could be used to do nearly anything which could ever be done on a PC. c. A good screen font creation and editing system for Turbo. d. A system for handling Dbase3 files. e. A system for handling Lotus (wks) files. f. A good asynchronous line handling routine for use in writing communications packages. g. Several very good general purpose window and menuing packages etc., including one, the QWIK21 library, which is actually better than any I've seen for C. h. A system for dealing with music exactly as Basic does; one simply changes the Basic "play" statements to "pibplay", a global editor change, and includes the handler .INC program in his code. i. A fast-fourrier transform system. j. A system for writing memory-resident programs in Turbo. k. A system for executing other programs from within a Turbo program. The driving force behind all of this is the $70 price tag, which has had the effect of generating 700,000 users out there, many of whom have bright ideas to contribute to the common pool of knowledge. This will also be true of Turbo C after a year or two. [whew, sorry to be so long-winded with that list, back to the original article] >2. A lack of a batch mode for compiles. Ever try to run Turbo Prolog from make? Ever try to run anybody else's Prolog from make? Correct me if I'm wrong, but I thought Borlands was the ONLY Prolog compiler and that all other implementations of Prolog were essentially interpreters, this being necessary to allow for the so-called "metalinguistic" features, the lack of which causes the hard-core AI freaks to decry TurboProlog the way they do. Have I missed something? >3. Bugs. I found several in Turbo Prolog, just screwing around for a day or >so (V1.0). Borland was nice enough to send me 1.1 unsolicited, but I haven't >verified that the bugs are gone. Why go with a new, untested product when there >are mature products around? The $100 price tag, speed (the up side of a compiled Prolog), module connectivity with other Turbo Languages, the good turtle graphics system, Philippe Kahn's winning smile...... By the way, have you ever gotten free upgrades to any other software products unsolicited? I know I never have. >I have been working for three years with C compilers daily, and have the >following two-bit reviews to offer: >1. MSC 4.0. Love codeview (but it has annoying bugs!), love the extensive >library. Code generation good to excellent. I haven't found any library bugs >myself, but supposedly if malloc fails, it will sometimes clobber DS. >ROM support sucks - regardless of the source they give you to startup. I regard 3.0 as satisfactory for small programs. Programs beyond 400 lines of code have always generated "module too large for post-optimization step" and other fun kinds of things, and I have encountered numerous failings which I regard as major. I haven't tried 4.0. >2. Aztec C86 - good to excellent code generation. Occasionally you will >still hit ugly code generation bugs in large models. Excellent ROM support. >Nice package of development tools, (make diff vi clone etc), but there are Failed every test I put it to, utterly failed to compile several standard UNIX items which the Mark Williams and Lattice compilers can readily handle, including the standard "cb.c". I didn't consider the Aztec compiler worth pursuing after that. I hate to say it; I see the Lattice and Mark Williams C compilers as the two best so far, which is pitiful. I plan to get a copy of Turbo C as close as I can to the first day it is available and put every copy of every other DOS C compiler which I have access to in the Potomac river where they belong. Ted Holden, IMS