Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!uwvax!persoft!eda From: eda@persoft.com (Ed Almasy) Newsgroups: comp.lang.c++ Subject: Re: C++ comparison Message-ID: <1990Aug29.161622.12404@persoft.com> Date: 29 Aug 90 16:16:22 GMT References: <2119@trlluna.trl.oz> <1990Aug24.181159.19680@cs.columbia.edu> Organization: Persoft, Inc. Lines: 149 In article <1990Aug24.181159.19680@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes: > >A COMPARISON OF >TURBO C++ (FIRST VERSION), GLOCK C++ 2.0A, ZORTECH C++ 2.1 >================================================================ > >I have had the opportunity to use turboc++ and Glockc++ extensively; >I have been experimenting with Zortech for the last 2 days. Here >are my impressions of the products, to help others decide which to get. I have been evaluating both Turbo C++ and Zortech C++ for the last couple of months. My results differ so strongly from yours that I felt compelled to throw my two cents in. :-) >summary: >============== > > Turbo c++ is best, except for programs with large c++ files, or > programs using Windows 3.0. ...or programs that require tight, fast code, or programs that need to make use of expanded memory, or programs that want to make use of comprehensive library support, or programs need to run under very tight memory constraints, or programs.....I could go on and on, but what's the point? Yes, the IDE shipped with Turbo C++ is much better than that shipped with Zortech C++, but is that what is important in a compiler? Buying a compiler because you like the menuing system provided in the IDE they ship with it seems to me like a foolish way to pick a development tool. (Perhaps you're not concerned about such mundane matters as quality of code generation, how comprehensive library support is, or whether library source code is available.) > ********** Zortech c++ ***************** > > * the compiler does not support huge pointers, meaning that it is >extremely cumbersome (and non-portable) to access data structures >larger than 64K bytes. For example, an array of structures, each >structure 16 bytes long, would be limited to 4000 entries. I guess I >will try making a C++ class to simulate a huge pointer, since the >application I am porting requires huge pointers. On the other hand, Zortech C++ supports the "handle" pointer type (Turbo C++ does not), which allows convenient access to expanded memory. Of the two problems solved by "huge" and "handle" pointers (accessing data objects larger than 64K and accessing more than 640K of memory) I would judge the one solved by "handle" pointers to be more important (and I think most MS-DOS software developers would agree with me). > * The editor that is part of the integrated environment does not >support pick lists! This means that when you want to open a file you >have to remember the name and type it all in! Get a clue, Zortech, >this is the 20th century. Heaven forbid! (Yet another critical compiler evaluation issue identified! :-)) > * Zortech is commended for providing a lengthy list of the bugs in >the product. However, these bugs should be fixed BEFORE adding extra >features to the integrated system. It is scary when a company prefers >to jazz up an interface before making the basic compiler correct. It would seem to me that this comment would be more applicable to Borland than to Zortech. I would also like to note that: 1) The bug list was far from "lengthy", and many of the "bugs" were actually quirks in the way the Zortech compiler behaved versus the way CFRONT behaves. 2) At least Zortech is willing to admit to problems with their product (unlike a couple of other companies who seem to do their level best to ignore them until they're forced into admission). > * The documentation is a pain. Typically I have to look at two >manuals and a readme document on disk when I have a question. Of >course, if it was a choice between perfect documentation and an >upgraded compiler I would prefer the latter. > > * The documentation has many errors. For example, section 19.2 says >"There is NO interactive mode (in Zorlib)", while section 19.2.1 is titled >"Using Zorlib with Interactive Prompts". Hmmm...perhaps we're reading two different sets of manuals? I've found Zortech's documentation to be outstanding (particularly for a company that probably doesn't have 100+ technical writers on staff), and have yet to find any significant errors in the text. But then, perhaps it's just that the manual sections that we're using are different. I've been working mainly with the compiler, function library, and toolkit manuals, rather than the IDE documentation. > * The compiler does not support as many options as Turbo; for >example it is impossible to turn off or on specific annoying warnings. Zortech does not allow the explicit suppression of various warning messages, but on the whole I have found the Zortech compiler much easier to use (in command line mode or from within makefiles) than the Turbo C++ compiler. I think this is mainly a function of Zortech trying to adhere to what C compiler command conventions exist in the MS-DOS world, while Borland goes off on their own tangent. > * The "make" command is under documented. They do not tell you >that environment variables are automatically defined as macros within >the make. (Zortech's "make" command is primarily UN*X "make" compatible.) > * Zortech provides the library source code with Zortech >Developer's edition, which is Great! However, the supplied makefile >would not execute correctly until I added a path to complex.hpp in the >makefile, and changed the command "lib" to "zorlib". My version compiled the libraries (with no errors) straight out of the box. >On the positive side are these points: > > * The compiler uses extended memory, and thus should handle quite >large input files. > > * the compiler is quick. > > * The supplied linker and librarian are largely Microsoft compatible. The supplied *library* is also largely Microsoft compatible (which Turbo C++'s is emphatically *not*), and it is also *MUCH* more extensive than that supplied with Turbo C++. > * The debugger appears quite capable, though I have yet to use it. The debugger IS quite capable and (IMHO) has better support for C++ than that supplied with the Turbo Debugger. Also, Zortech's debugger remembers all of the environment settings from the last time you ran it. None-Too-Humble Summary: :-) ------------------------ On the whole I found the Zortech development package to be a much better choice (than Turbo C++) for professional, time-critical, commercial project development. The Zortech compiler and associated utilities were much easier to integrate with existing development tools, and the documentation and library support provided with Zortech C++ were by far the best available from any of the major C/C++ compiler vendors. Once we took a hard look at the compiler support provided and did some realistic benchmarking, it was an easy choice.