[comp.sys.ibm.pc] TurboC vs QuickC vs MS C/v5.0

bob@imsvax.UUCP (Bob Burch) (02/22/88)

.....................................................................
Ted Holden
HTE   
 
 
 
          The Feb.  88 issue  of the PC Tech Journal contains a fairly
     detailed comparison of several of the top DOS C compilers  on the
     market today,  as well  as well  as a  couple of  articles on the
     state of C in the micro world today.  Julie  Anderson, writing in
     the "Systems Perspective" column states that "the [MicroSoft v.5]
     C optimizing compiler produces  the best  performing code  of all
     the compilers  we reviewed".   I  would suggest that Ms. Anderson
     either begin reading her own magazine or learn to count.
 
          On page 63 of the article, I count 30 measures  of speed for
     compiled code,  counting the  items on  either side of slashes as
     seperate items, with Turbo C beating MC5 on 15 counts  and losing
     to MC5  on 14, one draw.  The only item which shows a substantial
     difference between the  two  was  the  unformatted  read/write to
     disk,  which  Turbo  C  lost  rather  badly,  despite winning the
     getc/putc comparison.  Turbo beat MC5 in all  but one  measure of
     arithmetic speed.   TurboC  was faster than QuickC in all but one
     or two of the  tests,  often  by  considerable  margins.   TurboC
     always generated smaller code than either QuickC or MC5.
 
          The natural  comparison for performance obviously is between
     MC5 and  Turbo;   QuickC wasn't  in the  running.   A funny thing
     about  the  comparison  was  that  the times given on page 63 for
     Turbo were for code generated by the Turbo  integrated system and
     not by  TCC.  You'd have to assume code generated by TCC might be
     a little faster.  And, of course, compile  times for  Turbo are a
     lot faster  than for  MC5.   This translates into such real-world
     measures of efficiency as projects done on time and money  in the
     user's pocket.
 
          TurboC generally  checked out  as having  more features than
     MC5, one more memory model, inline code, graphics  support (which
     QuickC has  but 5.0  apparently doesn't),  and low-level keyboard
     support.     TurboC  checked   out  as   having  slightly  better
     documentation than  MC5 as well.  As far as I could tell, reading
     the entire article, Turbo C  was  the  winner,  pure  and simple.
     This is  all the  more remarkable  considering the  prices of the
     compilers in the comparison.
 
          The article pretty much neglected to mention one final point
     which I  would regard as rather critical.  The present version of
     Turbo is the second one.   There were  about ten  or twelve basic
     kinds of  bugs which  anyone ever found in Turbo 1.0, only one of
     which would ever be seen by Joe Average User.  You have to assume
     that all  such or at least ALMOST all such bugs are gone in Turbo
     1.5.  Compare this to the kinds of things you  keep reading about
     MC5 and quickC:
 
          "MC5 destroys hard disk!!!, Woe is me!!!", "MC5 adds numbers
          wrong!!", "QuickC involved in  fatal conflict  with Western-
          Digital controller,  user can't  get refund!!", "MC5, QuickC
          don't recognize Hercules Card!!",  "MicroSoft compiler fries
          FAT  table!!!",  "Programmer  becomes sterile and loses hair
          due to Microsoft C compiler!!!", etc. etc. etc.
 
     Who needs it?  The bottom line seems to  be that Borland  is  one
     whole generation ahead of MicroSoft in C compiler technology.
 
          I say let Microsoft do things they're good at, such  as OS's
     and assemblers,  and buy  your high-level compilers from somebody
     who's good  at producing  high-level compilers,  such as Philippe
     Kahn.
 
     Ted Holden
     HT Enterprises
 

romkey@kaos.UUCP (John Romkey) (02/23/88)

In article <788@imsvax.UUCP> bob@imsvax.UUCP (Bob Burch) writes:
>          TurboC generally  checked out  as having  more features than
>     MC5, one more memory model, inline code, graphics  support (which
>     QuickC has  but 5.0  apparently doesn't),  and low-level keyboard
> support
>
>     Ted Holden
>     HT Enterprises


Well, MSC 5.0 does have the graphics support. I've used it with the 5.0
compiler (as opposed to QuickC which I didn't even bother to install)
It just doesn't always work quite right....
-- 
			- john romkey
		...harvard!spdcc!kaos!romkey
		       romkey@kaos.uucp
		    romkey@xx.lcs.mit.edu

madd@bu-cs.BU.EDU (Jim Frost) (02/23/88)

In article <788@imsvax.UUCP> bob@imsvax.UUCP (Bob Burch) writes:
>          I say let Microsoft do things they're good at, such  as OS's
>     and assemblers,  and buy  your high-level compilers from somebody
>     who's good  at producing  high-level compilers,  such as Philippe
>     Kahn.

This is really good advice (how many people saw MS Fortran?) but,
seriously, how good are MS OS's?  *Especially* when you have
problems....

I think that when applications start coming out for OS/2, we may find
that all of the things people have been complaining to uSoft about
concerning their languages will show up concerning their new pet
operating system.

Only time will tell, but I know where I'm putting my money.

jim frost
madd@bu-it.bu.edu

aja@i.cc.purdue.edu (Miek Rowan) (02/23/88)

In article <788@imsvax.UUCP>, bob@imsvax.UUCP (Bob Burch) writes:
>  
>           TurboC generally  checked out  as having  more features than
>      MC5, one more memory model, inline code, graphics  support (which
>      QuickC has  but 5.0  apparently doesn't),  and low-level keyboard
>      support.     TurboC  checked   out  as   having  slightly  better
>      documentation than  MC5 as well.  As far as I could tell, reading
>      the entire article, Turbo C  was  the  winner,  pure  and simple.
>      This is  all the  more remarkable  considering the  prices of the
>      compilers in the comparison.

	One thing I have to give usoft credit for is, in my opinion,m
ousatanding documentation in 5.0.  I use both compilers, often, and have come
to never open the tc manuals.  They have had a while to get this right, but
that doesnt change the fact that it is good docs.  And pretty too. :-)

Now if the tc integrated debugger turns out as good as codeview ......


miek