Xref: utzoo comp.lang.c:39887 comp.lang.c++:13915 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!gistdev!flint From: flint@gistdev.gist.com (Flint Pellett) Newsgroups: comp.lang.c,comp.lang.c++ Subject: Re: Microsoft/Borland C/C++ Message-ID: <1177@gistdev.gist.com> Date: 6 Jun 91 15:25:51 GMT References: <1991Jun05.183949.2909@lut.ac.uk> Followup-To: comp.lang.c Organization: Global Information Systems Technology Inc., Savoy, IL Lines: 52 S.Culverhouse@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@gistdev.gist.com