Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ncar!mailrus!uflorida!novavax!proxftl!markd From: markd@proxftl.UUCP (Mark Davidson) Newsgroups: comp.sys.ibm.pc Subject: Re: Microsoft Vs. Borland Message-ID: <839@proxftl.UUCP> Date: 30 Sep 88 14:18:54 GMT References: <876@galaxy> <1133@unccvax.UUCP> <2722@ima.ima.isc.com> <1142@unisec.usi.com> Reply-To: markd@proxftl.UUCP (Mark Davidson) Organization: Proximity Technology, Ft. Lauderdale Lines: 22 Summary: Expires: Sender: Followup-To: Distribution: Keywords: I certainly hope this doesn't start a flame war, but I'd like to throw in some comments in the endless "Turbo C/MS C/Quick C" discussion. I own both MSC 5.1 and Turbo C 1.5 (2.0 soon, hopefully). Although MSC's documentation is many times better than Turbo C's, I still like Turbo C, especially when I'm initially working on a program (mainly because Turbo's compile/link times are so much better). My experience with Quick C has not been a happy one. I was working on a project at my last job (a few months ago) and I started out using Quick C. I ended up completing the job with my own copy of Turbo C. Quick C is extremely picky about equipment configuration (especially display cards), can only debug medium model code in the integrated environment (I wasn't using medium model), and on several occasions took valid C code and generated object code that was never going to work correctly. I was amazed at all the problems I had with it. I don't know about you people, but my jaw about hit the ground when I ran CodeView on a program I had compiled with Quick C and saw that it had turned an if statement into a comparison that had nothing to do with the values I was comparing! Call me naive, but I had never had a compiler I was using generate just plain wrong code. -- In real life: Mark E. Davidson uflorida!novavax!proxftl!markd Proximity Technology Inc., 3511 NE 22nd Ave, Ft. Lauderdale FL, 33308 #define STANDARD_DISCLAIMER