toma@tekgvs.LABS.TEK.COM (Tom Almy) (11/30/89)
Well, I wasn't exactly flooded with responses, three to be exact. One promoted his companies C++ front end (Intek C++, $495), which is fine but I am really interested in a true compiler (which should be able to generate better code??). The second said to "watch Borland", but that the might not be fully C++ compatible. That is my fear -- Borland likes to set their own standards. The third said to look at the c++ newsgroup. I did that, searching for any postings mentioning "Zortech". My impression is that version 2.0 is buggier than 1.07! So with no positive inputs from anywhere, and a bunch of negatives, I have decided to wait it out for Borland and/or Microsoft. I might also consider JPI's rumored C++, as I am very impressed with their Modula-2. I should have known. My long standing rule is "Never buy any version '.0' software," and *all* of the Zortech releases have been '.0'. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
keffer@blake.acs.washington.edu (Thomas Keffer) (12/01/89)
In article <6427@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: > > >Well, I wasn't exactly flooded with responses, three to be exact. > >One promoted his companies C++ front end (Intek C++, $495), which is fine >but I am really interested in a true compiler (which should be able to >generate better code??). > >The second said to "watch Borland", but that the might not be fully C++ >compatible. That is my fear -- Borland likes to set their own standards. > >The third said to look at the c++ newsgroup. I did that, searching for >any postings mentioning "Zortech". My impression is that version 2.0 is >buggier than 1.07! > >So with no positive inputs from anywhere, and a bunch of negatives, I have >decided to wait it out for Borland and/or Microsoft. I might also consider >JPI's rumored C++, as I am very impressed with their Modula-2. I can't offer you an opinion of Modula-2 versus C++, but if you decide on the latter, definitely upgrade to Zortech 2.0. Version 1.07 was barely above the level of being a toy, 2.0 is for real. It has its share of bugs, but is far better than 1.07. No doubt Borland will do their normal thorough job if and when they come out with a compiler, but if you need one now, Zortech is perfectly usable. >I should have known. My long standing rule is "Never buy any version '.0' >software," and *all* of the Zortech releases have been '.0'. Well, 1.07 wasn't and it was pretty bad. 2.0 is, and it's pretty good. But, it ain't perfect. Don't say I didn't warn you! 'nuff said. --- Dr. Thomas Keffer | Internet: keffer@ocean.washington.edu Rogue Wave | BITNET: keffer%ocean.washington.edu@UWAVM Seattle, WA 98145 | uucp: uw-beaver!ocean.washington.edu!keffer (206) 523-5831 | Telemail: T.KEFFER/OMNET Disclaimer: We market C++ products that use Zortech, but otherwise have no connection.
mark@intek01.UUCP (Mark McWiggins) (12/02/89)
toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: >Well, I wasn't exactly flooded with responses, three to be exact. >One promoted his companies C++ front end (Intek C++, $495), which is fine >but I am really interested in a true compiler (which should be able to >generate better code??). *ahem* 'twas I ... No, a true compiler should be *faster in compiling* and probably easier to debug, but the quality of generated code when using a C++ translator then depends upon the underlying C compiler. A translator then gives you choice of the processor for which you generate code, as well: 8088 or 80386 or 34010, or whatever C compiler you have. No doubt native-code compilers will come to predominate in coming years, but for the moment Cfront certainly has a niche to fill. And obviously I'm totally prejudiced on this point ... -- Mark McWiggins Integration Technologies, Inc. (Intek) +1 206 455 9935 DISCLAIMER: I could be wrong ... 1400 112th Ave SE #202 Bellevue WA 98004 uunet!intek01!mark Ask me about C++!
gary@dvnspc1.Dev.Unisys.COM (Gary Barrett) (12/07/89)
In Mark McWiggins writes: > *ahem* 'twas I ... No, a true compiler should be *faster in compiling* and > probably easier to debug, but the quality of generated code when using a > C++ translator then depends upon the underlying C compiler. A translator > then gives you choice of the processor for which you generate code, as well: > 8088 or 80386 or 34010, or whatever C compiler you have. > > No doubt native-code compilers will come to predominate in coming years, but > for the moment Cfront certainly has a niche to fill. > > And obviously I'm totally prejudiced on this point ... Note that AT&T's first support of C++ was in fact a pre-processor which generated "standard" C source. I thought that was a great idea at the time, since we could write C++ programs and then feed the AT&T output to the target C compiler of our choice (not AT&T's, one which we considered more optimized for our particular target machine). AT&T's approach was flexible and valid for our particular requirements. So you may be prejudiced, but on good grounds, I believe. -- ======================================================================== Gary L. Barrett My employer may or may not agree with my opinions. And I may or may not agree with my employer's opinions. ========================================================================