Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!rutgers!cunixf.cc.columbia.edu!cs.columbia.edu!kearns From: kearns@cs.columbia.edu (Steve Kearns) Newsgroups: comp.lang.c++ Subject: Re: C++ comparison Message-ID: <1990Aug29.204436.16590@cs.columbia.edu> Date: 29 Aug 90 20:44:36 GMT References: <2119@trlluna.trl.oz> <1990Aug24.181159.19680@cs.columbia.edu> <1990Aug29.161622.12404@persoft.com> Reply-To: kearns@cs.columbia.edu (Steve Kearns) Followup-To: comp.lang.c++ Organization: Columbia University Department of Computer Science Lines: 93 In article <1990Aug29.161622.12404@persoft.com> eda@persoft.com (Ed Almasy) writes: >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. :-) > >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? > yes, if you spend alot of time developing software. >(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.) > turbo's library is very comprehensive; I believe source code can be purchased separately from the compiler, just as in Zortech. >Of the two problems solved by "huge" (turbo) and "handle" (zortech) pointers (huge pointers access data objects larger than 64K and handle pointers access data in expanded 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). I have been porting software from a workstation environment to the pc. In workstations and in all non-INtel architectures and in OS/2 2.0, huge pointers are the norm. Thus, porting to Zortech is quite painful since huge pointers are not supported. Not only that, but today I discovered that Zortech does not allow you to "new" any structures bigger than 64K. No, calling farmalloc() is not a workaround, since "new" also constructs objects. From my perspective, Zortech does not support real pointers or true C++ memory allocation. Also, now that the DMPI specification is out, expanded memory is not half as useful as extended memory. >... 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. That is hard to understand since Turbo has all the options of zortech, often spelled similarly, and then lots more. >My version compiled the libraries (with no errors) straight out of the box. you probably have Microsoft's lib in your path. >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. As I hope I made clear in my first posting, both compilers have crippling flaws: turbo does not support windows, is slower than zortech, is not MSC object code compatible, and worst of all cannot handle large enough files. Zortech does not support huge pointers or construction of large objects, and their integrated environment has some glaring flaws. Most people's choice will be clear from this short list. If your application does not indicate a clear choice, one should choose the compiler which will best be supported in the future. I expect that the next version of turbo will solve its space problems (they recently made a deal with rational of dos-extender fame), and also provide windows compatability. However, I believe Zortech has NO PLANS to support huge pointers or construction of large objects. An important reason to discuss these issues is to encourage the compiler companies to correct these flaws. so zortech and turbo, I hope you are listening! -steve (kearns@cs.columbia.edu)