kearns@cs.columbia.edu (Steve Kearns) (08/25/90)
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.
summary:
==============
Turbo c++ is best, except for programs with large c++ files, or
programs using Windows 3.0.
for Windows programming, zortech 2.1 + codeview is the way to go,
but there are glaring problems with this setup.
for the best manual on how iostreams works, use GlockC++. Or, if
you have to use commonview, you must use Glock. However, I would
suggest using Zortech 2.1 + codeview + a package like C++/Views (CNS)
instead.
(iostreams is the new stream standard for C++ 2.1)
details:
=============
********** TURBO c++ *****************
I am confident that the SUBSEQUENT version of Turbo C++ will be the
premier C++ development environment. However, the current version has
some fatal flaws involving the size of file it can compile and its
lack of Windows support. Turbo C++ is the only compiler which does
NOT use the rational dos extender technology to access extended
memory. They use VROOM (swapping out code, but not data) to minimize
the space problems, but I have run into the file size limitation
several times with Turbo C++. Zortech and Glock can compile larger
files on machines with extended memory.
The TC++ integrated environment is even better than that of TC.
Basically, everything works quickly, safely, and intuitively. The
system works so well you can concentrate on your program instead of
the user interface. One of my favorite features is the ability to
execute any dos program and capture the output in an editor window;
furthermore, the command that executes this program appears in a TC++
menu, and can be assigned a key. The debugger is seamlessly
integrated into the environment, and is simple to operate. The
compiler has every option you may want. I agree with the poster who
said that Zortech C++ is twice as fast as Turbo C++, which is twice as
fast as Glock C++.
The editor is not emacs compatible, which is bad in my book. It is
reconfigurable, but I have yet to try to emulate emacs. Instead, I
use epsilon and tcc in normal operation, and epsilon with the
integrated environment when debugging. Since turbo c++ remembers the
contents, size, and locations of all the windows at the end of an
editing session, entering the integrated environment puts you right
back where you were when you left. Very nice and very convenient.
When you open a file, there is no need to type in a filename; there is
a "pick list" of files and directories to choose from. A mouse is
fully supported, but I found the key controls quite intuitive (and I
am a committed macintoshian!). The only nit to pick about the user
interface is that when setting compiler options in a submenu, the menu
disappears after changing an option. Better would be to return to the
parent menu so that further options can be changed.
Turbo C++ comes with a full complement of support programs, such as
"make", "tlib", "touch", etc.. The turbo c++ make is the most
unix-like make I have seen (compared to microsoft and zortech). Turbo
supports iostreams nicely. And Turbo C++ Professional, at $199 I
think, is the best deal around by far.
********** Glockenspiel C++ 2.0a *****************
In a word, a dog. The previous version, 1.2e1, works much better than
this version. 2.0a often gave up, reporting an error NUMBER 90. This
error basically says "something went wrong and I dont know what".
Furthermore, the glock compiler calls Microsoft C, and I often got
errors reported from Microsoft C. Glock C++ has 2 or 3 compilation
phases, plus the microsoft C phase. Errors seem to take place between
all phases, at different times, which means you have to search through
all sorts of manuals to find the particular problem.
Glock does not come with an integrated environment, and it relies on
the codeview debugger.
********** Zortech c++ *****************
Zortech C++ 2.1 is a spectacular improvement over version 1.06 (which
was so bad that I swore never to use a Zortech product again! Of
course, here I am, forced to use it because of its windows
compatability. I have been pleasantly surprised.) If Zortech
continues to improve it with the same perseverence they have shown so
far, they might eventually give Turbo c++ a run for their money. Here
are some of the problems I have run into in the short time I have been
using Zortech, the worst problems listed first:
* 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.
* 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.
* Zortech claims Windows support, but they seem to say that one
cannot debug a Windows program using their debuggers. Instead, one
has to use Codeview, which is pretty bad.
* A chapter and a half of the documention is devoted to ZED, a
zortech editor. ZED provides pick lists. But Zed is not provided
with the Zortech Developer's edition (in contradiction to the
documentation.)
* the interface is clunky, not half as intuitive as that of turbo.
For example, if I pull down the File menu with alt-f, and then realize
that I want to pull down the Window menu, I cannot just hit Alt-W as I
could in turbo. Instead I have to use the arrow keys or hit escape
and then alt-w. Windows open too small to use, and I have to
immediately zoom them. The workbench does not remember my
configuration (what files are open, my additions to the "make" comand
line, etc..) Opening the same file twice gives two separate copies of
the file in memory, instead of returning to the previously edited
file. These are all small but annoying things that get in the way of
productive use of the integrated environment.
* 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.
* 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".
* The compiler does not support as many options as Turbo; for
example it is impossible to turn off or on specific annoying warnings.
* The "make" command is under documented. They do not tell you
that environment variables are automatically defined as macros within
the make.
* 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".
On the positive side are these points:
* The integrated editor emulates most of the basic emacs commands
and has extensive mouse support.
* 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 debugger appears quite capable, though I have yet to use it.
* The integrated grep and compiler-error browser are reasonable, though
Turbo's implementation is easier to use.bright@Data-IO.COM (Walter Bright) (08/28/90)
In article <1990Aug24.181159.19680@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes:
<* the compiler (Zortech) 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.
Let's say you want an array of 16000 16 byte structs. Here's how to do
it portably without the overhead of huge pointers:
struct S *arrayp[4];
#define array(i) arrayp[(unsigned)i/4000][(unsigned)i%4000]
/* Initialize: */
for (i = 0; i < sizeof(array) / sizeof(array[0]); i++)
array[i] = (struct S *) malloc(sizeof(struct S) * 4000);
Adjusting the value 4000 so it is a power of 2 makes the *,/ and %
turn into shifts.
To use, array(i) instead of array[i]. It will work as both an lvalue
or an rvalue. I would argue that it is both more space efficient and is
much faster than using huge arithmetic. It also does not suffer from the
problems that you get with huge model if sizeof(struct S) does not divide
into 64k evenly.
I've helped several people convert their code to Zortech from using huge
pointers, and this method, or minor variations of it, usually works fine.
I hope this helps...eda@persoft.com (Ed Almasy) (08/29/90)
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.
kearns@cs.columbia.edu (Steve Kearns) (08/30/90)
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)
toma@tekgvs.LABS.TEK.COM (Tom Almy) (08/30/90)
In article <1990Aug29.204436.16590@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes: >In article <1990Aug29.161622.12404@persoft.com> eda@persoft.com (Ed Almasy) writes: >>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. > There is another alternative. I spend a lot of time developing software and don't use anyone's IDE. Why? Because every IDE is different, and it is too much of a hastle to switch around. If I could get by with just one language, then an IDE would be great. But I use 4 different C compilers (2 with IDEs), Modula-2 (with an IDE, and another I don't use, with an IDE), 2 Fortran compilers (no IDE), Forth (IDE), LISP (IDE), Pascal (IDE), and BASIC (IDE). I use Epsilon and NDMAKE, and do just fine, thank you! (It may seem bazarre, but I have far more trouble switching editors than I do swiching programming languages!) Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
ronb@burklabs (Ron Burk ) (09/04/90)
eda@persoft.com (Ed Almasy) writes: > In article <1990Aug24.181159.19680@cs.columbia.edu> kearns@cs.columbia.edu (S > > > > > * 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). > Actually, the bug list that they publish has always been a small subset of the number of reported and documented bugs. I haven't had enough time with the latest release to tell, but certainly the real bug list for all previous releases always qualified as "lengthy". I don't think this is a symptom of dishonesty, just lack of organization and attention to detail. An important drawback of Zortech which I haven't seen mentioned is that ZTC misses significant error checks that TCC catches. For example, ZTC often does not detect that a function that should return a value does not. It also does not detect unused variables or function parameters by default. I agree with an opinion I saw earlier: they both have drawbacks and if you're a serious PC C++ developer, you'll want to make sure your code works with both of them.
patrickd@chinet.chi.il.us (Patrick Deupree) (09/04/90)
In article <8027@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: >(It may seem bizarre, but I have far more trouble switching editors than I >do swiching programming languages!) That's not bizarre at all. That's the main reason I don't really use the IDE from Borland. It's too difficult to switch IDE's since they're all very different, whereas languages, though the syntax is different, will always have the same general logic. Now, if there were a standardized debugger that would be just fantastic. @:) -- "What's in a name? That which we call a rose by any other name would smell as sweet." William Shakespeare Patrick Deupree -> patrickd@chinet.chi.il.us (708) 328-3800 (Please note there are both a patrick and a patrickd at this site)
bright@Data-IO.COM (Walter Bright) (09/06/90)
In article <06RXo1w161w@burklabs> ronb@burklabs (Ron Burk ) writes: <An important drawback of Zortech which I haven't seen mentioned is that ZTC <misses significant error checks that TCC catches. For example, ZTC often <does not detect that a function that should return a value does not. It does not do this deliberately, a lot of C code exists that is written like: func() { .... } instead of: void func() { .... } <It also does not detect unused variables or function parameters by default. This is also deliberate because: 1. The optimizer frequently removes all uses of a variable, this can cause annoying spurious error messages. An example is when a loop index is replaced by a pointer. 2. I frequently write code like: void func(int i,int j) { /* fill in the body later */ } and don't want to be annoyed by a blizzard of messages. 3. I have several programs which call a function pointer pulled out of a table. By necessity, all the functions in the table have the same parameters, but probably most of the implementations of the functions leave some of the parameters unused. I'd say that these are differences of opinion between us, and are not necessarilly bugs.
hardin@hpindda.cup.hp.com (John Hardin) (09/06/90)
patrickd@chinet.chi.il.us (Patrick Deupree) writes: > In article <8027@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: > >(It may seem bizarre, but I have far more trouble switching editors than I > >do swiching programming languages!) > > That's not bizarre at all. That's the main reason I don't really use the > IDE from Borland. It's too difficult to switch IDE's since they're all very > different, whereas languages, though the syntax is different, will always have > the same general logic. --------- Turbo C++ has introduced a nice feature in its IDE that allows me to configure a hot-key that brings up my favorite editor and feeds the current file to it. That way I can use their IDE and not have to use their editor. John Hardin hardin@hpindgh.hp.com -------