[comp.sys.ibm.pc] Zortech C++ compatibility with existing graphics libraries

bob@imspw6.UUCP (Bob Burch) (01/01/89)

 
 
From Ted Holden, HT enterprises:
 
 
.......................................
 
 
From: rchen@m.cs.uiuc.edu (Ron Chen)
 
 
>I wish Zortech could generate (as an option) Turbo C compatible object code
>so I can link it with my Turbo C graphics libraries.  I consider it as a great
>drawback that Zortech is incompatible with any of the existing well known
>C compilers on MS-DOS.  Zortech is a good choice if you want to learn C++
>but it is too primitive to do anything real.
 
 
As I have stated once on USENET, Zortech C++ is totally compatible with the
Turbo C version of the MetaWindow/MetaGraphics library, reputed to be the
fastest and best of the DOS graphics libraries, and a $80 item from Programmers'
connection.  When you do one thing for a living, you tend to get good at it;
Metagraphics is being used for several X-11/PC projects, and it is a DAMNED
sight better than the standard Borland graphical system which comes with
Turbo C.  C++ applications I have written with classes of graphical creatures
which move accross the screen simultaneously require timing loops to slow the
action down for humans to follow easily.
 
Beyond any of this, the present version of Zortech C++, 1.07, handles all of
the examples in both Stroustrup's book and in the Pinson/Weiner book and is,
thus, regarded as a completely workable baseline.  There is no noticable
drop-off in speed of applications code from Turbo C;  brother, that's fast.
Zortech is presently hard at work on C++ tool libraries as well as on elegant
solutions to the problem of debugging object-oriented code.
 
I don't know what your definitions of primitive/serious are, but the Zortech
compiler strikes me as awfully serious and as a soon-to-be major player in
the DOS programming world and, hopefully, in the 386/486 desktop UNIX world
which is around the corner.
 
 
Ted Holden
HTE
 
 
 
 
 
 

feg@clyde.ATT.COM (Forrest Gehrke) (01/03/89)

> From Ted Holden, HT enterprises:
>  
> I don't know what your definitions of primitive/serious are, but the Zortech
> compiler strikes me as awfully serious and as a soon-to-be major player in
> the DOS programming world and, hopefully, in the 386/486 desktop UNIX world
> which is around the corner.
> Ted Holden
>  

I ordered an update to C++ from Zortech in October which was promised
for late November.  This update was supposed to be compatible with
MS Codeview.  Anybody else seen this yet?  I have received nada.



Forrest Gehrke

toma@tekgvs.GVS.TEK.COM (Tom Almy) (01/05/89)

In article <39008@clyde.ATT.COM> feg@clyde.ATT.COM (Forrest Gehrke) writes:
>> From Ted Holden, HT enterprises:
>> I don't know what your definitions of primitive/serious are, but the Zortech
>> compiler strikes me as awfully serious and as a soon-to-be major player in
>> the DOS programming world and, hopefully, in the 386/486 desktop UNIX world
>> which is around the corner.
>
>I ordered an update to C++ from Zortech in October which was promised
>for late November.  This update was supposed to be compatible with
>MS Codeview.  Anybody else seen this yet?  I have received nada.

Well, when my copy of C++ came, the BUNCH.EXE program, which is supposed
to make it posible to use Codeview (except for local variables, of course),
was a *ZERO* length file.  Two phone calls later, they promised to send
out a disk with the program.  A disk arrived with a label which had penned
on it "Bunch.exe", but the disk contained only two mysterious .lib files.
My conclusion is that BUNCH.EXE does not work.

My opinion is that the only way they will become "serious" and a "major
player" is via the steam roller effect C++ is having.  I found about a
dozen bugs, worse than any compiler I have used.  When I called with a
bug report I found that they were distributing *simultaneously* two 
different versions (perhaps they will go with the one that produces the
fewest bug reports?).  One of the compiler's most common error message was
to crash.

The package also shows immaturity in that there are no C++ example programs
on disk, and the only provided class is "stream", which is not documented.

Tom Almy
toma@tekgvs.tek.com
Standard Disclaimers Apply

feg@clyde.ATT.COM (Forrest Gehrke) (01/06/89)

In article <4457@tekgvs.GVS.TEK.COM>, toma@tekgvs.GVS.TEK.COM (Tom Almy) writes:
> In article <39008@clyde.ATT.COM> feg@clyde.ATT.COM (Forrest Gehrke) writes:
> >> From Ted Holden, HT enterprises:
> >> I don't know what your definitions of primitive/serious are, but the Zortech
> >
.> >I ordered an update to C++ from Zortech in October which was promised
.> >for late November.  This update was supposed to be compatible with
.> >MS Codeview.  Anybody else seen this yet?  I have received nada.
.> 
.> Well, when my copy of C++ came, the BUNCH.EXE program, which is supposed
.> to make it posible to use Codeview (except for local variables, of course),
.> was a *ZERO* length file.  Two phone calls later, they promised to send
.> out a disk with the program.  A disk arrived with a label which had penned
.> on it "Bunch.exe", but the disk contained only two mysterious .lib files.
.>  [deletions....] 
.
.> player" is via the steam roller effect C++ is having.  I found about a
.> dozen bugs, worse than any compiler I have used.  When I called with a
.>  [deletions....] 
.> The package also shows immaturity in that there are no C++ example programs
.> on disk, and the only provided class is "stream", which is not documented.
.
I understand Zortech is a British company.  My experience with them 
shows them to be unexpectedly inept.  When I first ordered the compiler
I also ordered the source code.  The compiler was shipped minus the
source code.  Seven weeks later and three phone calls finally
produced the source code.  Now it looks like they have lost my
order for the update.  From the report by Tom it appears I shouldn't
push too hard until they fix some more bugs.

   Forrest Gehrke

english@panarea.usc.edu (Joe English) (01/13/89)

In article <39129@clyde.ATT.COM> feg@clyde.ATT.COM (Forrest Gehrke) writes:
>
>I understand Zortech is a British company.  My experience with them 
>shows them to be unexpectedly inept.  When I first ordered the compiler
>I also ordered the source code.  The compiler was shipped minus the
>source code.  Seven weeks later and three phone calls finally
>produced the source code.  Now it looks like they have lost my
>order for the update.  From the report by Tom it appears I shouldn't
>push too hard until they fix some more bugs.
>

Hm, that's odd.  I had no problem getting the source code
with my order (which I'm glad I ordered, since what little 
C++ code is contained in the library, isn't documented except 
in header files).  Though I haven't gotten the newsletter yet, which
I thought I was supposed to...

I have version 1.06 of the compiler and haven't had any
problems with it, as long as my source code is correct.
I find that it often chokes on stuff like missing
semicolons and improper function call syntax: with the
"Zortech error: ####" message (which, according to the
manual, means 'serious compiler error, contact Zortech.')

Which versions are known to be full of bugs?  My only worry
is: does it produce correct code?  I don't care how broken
the function inliner or the error recovery scheme is, as
long as I get what I write.  And what are those bugs?

I would like to add that, outside of the poor error
recovery and documentation, I find Zortech C++ to be an
excellent product, with relatively fast compiles (not as
good as Turbo C, though) and fast object code (better than
Turbo C.)  I'm glad I made the switch.


      /|/| Joe English
-----< | | 
  O   \|\| english%lipari@oberon.usc.edu

hardin@hpindda.HP.COM (John Hardin) (01/17/89)

/ english@panarea.usc.edu (Joe English) writes:

I have version 1.06 of the compiler and haven't had any
problems with it, as long as my source code is correct.
----------

FYI, I've found a problem with 1.06 even when the code is correct.
I was compiling with the small model when I noticed that the destructor
of a base class is not called when an object of a derived class goes
out of scope.  Further testing showed that this bug occurs in the 
small and medium models, but not the compact or large models.

I've called Zortech about this but everyone was busy so the operator
took my name and number.  No call back yet (this was last week some
time).  Anyone out there know if this is also a problem in 1.07?

John Hardin
hardin%hpindda@hplabs.hp.com