Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!cwruecmp!hal!ncoast!kent
From: kent@ncoast.UUCP
Newsgroups: comp.sys.ibm.pc,comp.lang.c
Subject: Turbo C
Message-ID: <2104@ncoast.UUCP>
Date: Fri, 20-Feb-87 08:56:12 EST
Article-I.D.: ncoast.2104
Posted: Fri Feb 20 08:56:12 1987
Date-Received: Sat, 21-Feb-87 10:52:52 EST
Distribution: comp
Organization: Cleveland Public Access UNIX, Cleveland, OH
Lines: 38
Xref: utgpu comp.sys.ibm.pc:1816 comp.lang.c:1116

s/*** REPLACE THIS LINE WITH YOUR MESSAGE ***/YOUR MESSAGE/g

A number of people have posted inquiries about Borland's Turbo C.  The
following is an editorial of sorts, along with some biased and unsolicited
opinions of MS-DOS C compilers.  I am associated with NONE of the companies
discussed.

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.

2. A lack of a batch mode for compiles.  Ever try to run Turbo Prolog from make?

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?

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.

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

them