Microsoft/Borland C/C++

[Flint Pellett]

S.Culverhouse at lut.ac.uk (Bizee Bee - Simon C.) writes:

> [comments deleted]
> .....  So far I have been unimpressed with Turbo C++,
> especially with the environment.  Although the code I used, developed under
> QuickC, usually compiled first time, without any problems, on the Turbo C++, I
> found that it took longer to do so, and indicated that it was eating up memory,
> at such a rate, that if I had tried to compile anything larger, it would not 
> have coped.  It also looked to me, as though MS-C actually produced faster code
> especially with screen handling routines.

> In general I still prefer good old Microsoft C, and am relutant to change.  I
> am however open to suggestions and views on the two compilers, and would
> apreciate any mail from other MS / Turbo C users.

I just completed a project where I built a fairly large program (14K lines of
C source) using each of MSC5.1, Turbo C++ 2.0, and Watcom C 7.0.  (These
three are compilers are all now 1 version out of date since MSC has v. 6.0,
Borland has their Borland C++, and Watcom has v. 8.0.)  I won't comment on
C++ advantages, since this was all pure C.  I didn't use MS's QuickC or
Watcom's Express C, or any of the integrated environments, I was using
makefiles and running from the shell prompt.  I found roughly the following
ratios in performance in various areas.  (The ratios are deliberately vague:
relative performance varied from module to module, but if both of them have
a 1.0 then they are roughly the same.)

			MSC	Turbo	Watcom
Code Size		1.0	1.05	0.8
Execution Speed		1.0	1.0	0.8
Compile Time		1.0	0.6	0.9
Debugging Info		1.0	1.4	1.4

In the particular case I had Watcom's size became an even bigger win,
because it became enough smaller that I was able to move to a smaller
memory model and ended up with a program more than 30% smaller and
even faster.  (I would bet there are a lot of programs in the 70K to
90K size that could slip under 64K with Watcom.)  When Turbo compiles
with the debugging flags on the program gets big, and a lot of people
think that means Turbo is not generating code that is as good.  All it
really means is that more useful info to aid debugging is being kept
around.  The ratios on debugging info are subjective, based on my
perception of how useful error diagnostics were to me to correct
coding problems: both Turbo and Watcom (at maximum warning level)
warned me about bad code conditions that MSC ignored.  In one case, a
warning WATCOM generated and the others provided no message on
resulted in an execution time bug.  AT&T SYSV 3.2's lint program did
not even warn me about that one: in fact, I cleaned up several
things lint didn't catch based on Turbo and Watcom warnings.
-- 
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL  61874     (217) 352-1165
uunet!gistdev!flint or flint at gistdev.gist.com