jdb@reef.cis.ufl.edu (Brian K. W. Hook) (05/12/91)
While perusing the April 8 issue of InfoWorld I noticed they did a comparison of C compilers. I am posting a summary for those that may be interested. EXECUTIVE SUMMARY: "The best overall package is Borland C++ 2.0. It provides a superb integrated environment for developing both DOS and Windows applications. Inclusion of the Whitewater Resource Toolkit obviates the need for the MS SDK for Windows, a less robust tool set. Our only complaints are the lack of OS/2 support and the fact that the Programmer's Platform, Borland C++'s integrated development environment, is not a Windows application. Zortech C++ 2.18 is a worth competitor. Its WorkBench integrated environment is delightfully easy to use, and this package, unlike Borland C++, has a variety of object tools if you want to take advantage of its object-oriented programming capabilities. Debugging tools could be improved only with the addition of a Windows debugger. You can't go wrong with MSC 6.0a, the de facto industry standard. It's one of two packages here that supports DOS, Windows, and OS/2. Programmer's Workbench is an excellent development environment, and CodeView takes the pain out of Debugging. Overall, Microsoft C is the best choice for someone who needs only a straight C compiler. Watcom C, versioy n8.0 also supports DOS, Windows, and OS/2 development. Its integrated environment is still somewhat immature, but the debugger is superb and offers great verstaility in remote debugging. At only 250 dollars, Lattice C 6.05 is priced right. It supports DOS and OS/2 applicatioms development and includes an excellent set of application libraries. Without the benefit of an update for almost a year, Lattice C is struggling to keep up with the times. Nevertheless, for someone looking for an inexpensive, quality C compiler, Lattice would be a good choice. MetaWare C, 1.61, is a straight C compiler with some utilities thrown in. You'll have to provide your own debugger, Make utility, linker, and other tools. Because it costs so much for so little, it's difficult to recommend it." WELL, that's it. Some comments that I would like to throw in are that the Programmer's WorkBench of MSC, in my opinion, is HIDEOUS. Also, the magazine fails to include Turbo C++ (a 70 dollar competitor) which would've been a KILLER against Lattice C. The lack of including Mix C, another efficient low cost compiler, was an injustice to Mix Software. Other than that, I hope that was informative. Brian
coy@ssc-vax (Stephen B Coy) (05/17/91)
In article <28483@uflorida.cis.ufl.EDU> jdb@reef.cis.ufl.edu (Brian K. W. Hook) writes: >You can't go wrong with MSC 6.0a, the de facto industry standard. It's one >of two packages here that supports DOS, Windows, and OS/2. > >Programmer's Workbench is an excellent development environment, and >CodeView takes the pain out of Debugging. Overall, Microsoft C is the best >choice for someone who needs only a straight C compiler. Assuming, of course, that you have at least a fast 386 to run all this on. And you don't mind a buggy compiler. >At only 250 dollars, Lattice C 6.05 is priced right. It supports DOS and >OS/2 applicatioms development and includes an excellent set of application >libraries. Without the benefit of an update for almost a year, Lattice C >is struggling to keep up with the times. Nevertheless, for someone looking >for an inexpensive, quality C compiler, Lattice would be a good choice. Lattice has some serious downfalls that in my mind make it unacceptable. a) The price really isn't that great especially compared to Turbo C++. b) The compile speed is noticably slower than Microsoft which is in turn slower than Borland. c) The executable speed is about 5% slower than MSC 5.1. d) The reason there hasn't been an update in the past year is because SAS (who bought Lattice) has decided that they don't have the resources to compete with Microsoft and so will not be putting out new versions of the compiler. It's a dead-end product. e) While they do continue to provide support for the compiler they have recently switched over to a pay-for-support scheme. f) The scheme for selecting which memory model library you link to is real ugly. All the libraries have the same name but are in different subdirectories. You have to change the LIB environment variable to reflect whatever memory model you currently want. The is fixed in their 286 developer's kit which in addition to coming with a dos-extender (yeah) also comes with a dongle (hiss). g) The manuals are a pain to deal with. While they may be complete, everytime I look for something in the index it's not where I expect it to be and the page numbering scheme assumes that you know which sections are in which of the 4 3-ring binders the docs come in. Stephen Coy coy@ssc-vax.UUCP BTW I own Lattice C 6.0, Lattice C 286 Dev Kit, Borland C++ and soon the Intel 386/486 C Code Builder's Kit. I also regularly work with MSC 5.1 and 6.0 and Watcom C 386 8.0. The comment about executable speed was based on running my ray tracer, a fairly floating point intensive task. I guess my attitude about Lattice can be summed up by saying that I'd love to sell my copy of 6.0 but I'd feel guilty sticking anybody with this package at any price.
epiren@rivm.nl (I.A.Kreis) (05/22/91)
In article <3992@ssc-bee.ssc-vax.UUCP> coy@ssc-vax.UUCP (Stephen B Coy) writes: > . . . . You have to change the LIB environment variable to >reflect whatever memory model you currently want. You don't have to specify the LIB variable. You don't have to link either. It is a compiler, not a linker. They DO give away alinker with the compiler package, which in my case works well. The LMB (linker) accepts full pathnames, which can be easily found in the first of T4FM's, but I agree, just experimenting with it is a quicker way to find out. Flaming is even quicker. Adriaan van Kessel epiren@rivm.nl
coy@ssc-vax (Stephen B Coy) (05/24/91)
In article <1991May21.175117.4101@rivm.nl> epiren@rivm.nl (I.A.Kreis) writes: >You don't have to specify the LIB variable. You don't have to link either. >It is a compiler, not a linker. They DO give away alinker with the compiler >package, which in my case works well. The LMB (linker) accepts full pathnames, >which can be easily found in the first of T4FM's, but I agree, >just experimenting with it is a quicker way to find out. Flaming is even >quicker. Yes this works just fine but why should I have to explicitely specify the path to the library I want to link with? On the command line I've already specified the memory model I want so why can't Lattice figure out which library that corresponds to? Every other compiler on the market can. As I also noted, Lattice has fixed this behavior in their 286 (and I assume 386) developer's kits. Since Lattice is no longer providing updates I assume it will never be fixed in the basic package. I find this kind of behavior unacceptable in a compiler especially in light of InfoWorld's recommendation of Lattice as a good package for beginners. Sorry if I touched a nerve but I stand by my assertion that if you are going to buy a compiler, Lattice is not a good choise. >Adriaan van Kessel >epiren@rivm.nl Stephen Coy coy@ssc-vax.UUCP BDIF