root@softeng1.UUCP (Lyle Zumbach) (09/12/89)
What C++ translators/compilers are available for DOS or OS/2? Is Microsoft marketing a C++ product? When will Microsoft or Borland be selling a C++ 2.0 compiler?
sidney@saturn.ucsc.edu (Sidney Markowitz ) (09/12/89)
In article <293@softeng1.UUCP> root@softeng1.UUCP (Lyle Zumbach) writes: >What C++ translators/compilers are available for DOS or OS/2? >Is Microsoft marketing a C++ product? >When will Microsoft or Borland be selling a C++ 2.0 compiler? PC Week (9/4/89) said that "the next version of the Turbo C compiler will incorporate [...] C++", that OS/2 development has been put on hold due to lack of market demand for an OS/2 product, and that the next version of Turbo C is due out in 1990, though Borland may decide to ship a partial implementation of C++ 2.0 to get the product to market faster. Disclaimer: I am only quoting the PC Week article, and making no claims as to what I know, don't know, care about, or don't care about. -- sidney markowitz <internet: sidney@saturn.ucsc.edu or sidney@ai.mit.edu>
jeenglis@nunki.usc.edu (Joe English) (09/12/89)
root@softeng1.UUCP (Lyle Zumbach) writes: >What C++ translators/compilers are available for DOS or OS/2? Zortech sells a good C++ compiler for MS-DOS at an excellent price -- $100, $150 with library source -- It doesn't fully support any of the 2.0 features (not yet anyway; Walter?) but it does support everything in The Book. Personally, I've found it to be a very good product. The address is: Zortech Inc., Massachusetts Avenue Arlington MA 02174 (617)6466703 >Is Microsoft marketing a C++ product? >When will Microsoft or Borland be selling a C++ 2.0 compiler? To my knowledge, not now and there haven't been any press releases, so there probably won't be for a while. --Joe English jeenglis@nunki.usc.edu
kearns@read.columbia.edu (Steve Kearns) (09/12/89)
I would recommend AGAINST going with Zortech. The product (1.07, the latest version as far as I know) has some very serious bugs which generate incorrect code. And the bugs are such that they can bite you in very subtle ways. The best product I have found is the Glockespiel 1.2E1 version of the AT&T translator. This comes with the ImageSoft CommonView package, though it is probably available elsewhere. They also have a version 1.2E1/16m which uses extended memory and thus allows much larger files to be compiled. Unfortunately this latter product sometimes bombs out, which they proudly state in their documentation. Also, Glock 1.2e1 is built ontop of the microsoft C5.1 compiler (you must have it to use 1.2e1, I believe). This means it can be used with standard libraries, which is not the case with Zortech. Personally, I cannot wait for the Turbo people to come out with a C++. Turbo C is #1, and I am sure that their C++ will also be topnotch. ------------------------------------------ News Flash! Lightspeed C Messes Up! Think C, formerly Lightspeed C, is one of the best development environements for C available on any machine (but it runs only on the Mac). It features lightening fast compiles and an integrated makefile/editor/compiler/debugging environment. The bad news is that they recently shipped an update with object oriented features. In fact, it is Yet Another Incompatible Scheme for OOP in C, along the lines of C_Talk etc... It is a real kludgy system where you have to call a new() function to create an object, all objects are actually pointers or handles, and other grossness. They tried to create a system which you will be able to recompile with a C++ compiler and have it still work, but their object system has very little in common with C++. I suppose they felt the need to be able to say their product is Object Oriented. But I suspect word will get out about the reality. Now they have sentenced themselves to supporting a kludgy system from here on out, even when they finally implement C++. Oh well. -steve
SRWMRBD@windy.dsir.govt.nz (ROBERT) (09/13/89)
Joe English writes >Zortech sells a good C++ compiler for MS-DOS at >an excellent price -- $100, $150 with library source -- >It doesn't fully support any of the 2.0 features >(not yet anyway; Walter?) but it does support everything >in The Book. Personally, I've found it to be a very good >product. It is a good product but it doesn't support everything in The Book. For example, don't expect user defined conversion operators to work and do expect some expressions to mis-compile. Robert
nagle@well.UUCP (John Nagle) (09/14/89)
In article <6492@columbia.edu> kearns@read.UUCP () writes: > >I would recommend AGAINST going with Zortech. The product (1.07, the >latest version as far as I know) has some very serious bugs which >generate incorrect code. And the bugs are such that they can bite you >in very subtle ways. Can you be more specific? I've found a bug in Zortech 1.07 where incorrect code is generated. It seems to be associated with the "?" operator. Interestingly, when the function involved are changed to "inline", the problem goes away. I would report the problem to Zortech, but they haven't yet replied to my registration card. John Nagle
kearns@read.columbia.edu (Steve Kearns) (09/14/89)
In article <13588@well.UUCP> nagle@well.UUCP (John Nagle) writes: >In article <6492@columbia.edu> kearns@read.UUCP () writes: >> >>I would recommend AGAINST going with Zortech. The product (1.07, the >>latest version as far as I know) has some very serious bugs which >>generate incorrect code. And the bugs are such that they can bite you >>in very subtle ways. > > Can you be more specific? > ..... > John Nagle Previously in this group someone pointed out that user defined conversion operators are not supported. But the most serious bug I know of was, very responsibly we should notice, reported by the Zortech's author Walter Bright. Objects returned by value are stored in a static location instead of the stack, meaning that expressions that require two subexpressions to be calculated will overwrite each other. Even more frightening is the unknown: what other bugs are there that we DONT know about? -steve
wlp@calmasd.Prime.COM (Walter Peterson) (09/14/89)
In regards to Zortech C++ bugs... In article <6496@columbia.edu>, kearns@read.columbia.edu (Steve Kearns) writes: > > Even more frightening is the unknown: what other bugs are there that > we DONT know about? > That is true of *ANY* software. If it is frightening for a PC compiler, just think about so-called Strategic Defense Inititive ! -- Walt Peterson. Prime - San Diego R&D (Object and Data Management Group) "The opinions expressed here are my own."
collin@hpindda.HP.COM (Collin Park) (09/15/89)
re zortech c++: there is a review of zortech c++ in the 9/89 _Computer_, page 89, by R. Tenney. I have no experience with any zortech product, so i cannot validate or contradict tenney's review -- but thought it might be of interest to this group. ------------------------------------------------------------------------------ Unless explicitly stated otherwise, opinions expressed above are my own and do not explicitly reflect those of the Hewlett-Packard Company or any other person or entity. collin park Hewlett-Packard Company collin%hpda@hplabs.hp.com 19420 Homestead Road -- MS 43LT Cupertino, CA 95014 USA
SRWMRBD@windy.dsir.govt.nz (ROBERT) (09/15/89)
Steve Kearns writes >I would recommend AGAINST going with Zortech. The product (1.07, the >latest version as far as I know) has some very serious bugs which >generate incorrect code. And the bugs are such that they can bite you >in very subtle ways. >The best product I have found is the Glockespiel 1.2E1 version of the >AT&T translator. This comes with the ImageSoft CommonView package, though .... I suggest you not expect too much from the Glockenspiel 1.2E1 C++ translater for MsDos unless you have a 386 with user area extended to 900K. Otherwise two medium sized hxx files will make the translater run out of storage. And you are going to need lots of hxx files if you are into reusable software. And when you include the time taken by the Ms C compiler, compiler times are long and so are the code files. The glockenspiel compiler is useful for verifying that ones C++ program developed with Zortech will compile on something closer to AT&T and for trying to see if a problem is yours or Zortech's. (Zortech can also be used to see if a problem is yours or Glockenspiel's) The cost is getting significant. Zortech seems to cost about $150 and my update to 1.07 cost me $20. Glockenspiel cost me $495 from Oasys for a version that was so buggy it wasn't worth wasting time with plus $350 for the upgrade from ImageSoft. Its really the cost of the upgrade that hurts. And in this part of the world the costs of updating the C compiler also hurt. The answer maybe is there is not a really satisfactory C++ compiler or translater for MsDos on PCs or 286 ATs. But I am still pretty impressed with Zortech. Someone who reads this news group wrote saying they were working on a 386 compiler. Maybe they should report progress.
schwartz@dinl.uucp (Michael Schwartz) (09/15/89)
In article <661@windy.dsir.govt.nz> SRWMRBD@windy.dsir.govt.nz (ROBERT) writes: > >I suggest you not expect too much from the Glockenspiel 1.2E1 C++ >translater for MsDos unless you have a 386 with user area extended to >900K. Glockenspiel has done a good job in 1.2E1 of a) rolling out low memory used by make and the front end to effectively add about 84K of DOS memory--enough for hierarchies that are not too deep b) providing an optional product which uses Rational System's 16M 286 protected mode for direct access to extended memory to aid in compilation. Cost is $100 to owners. It properly uses XMS (version 2.0 and above...) > >The cost is getting significant. You bet. MAJOR advantage of Zortech. One additional advantage of ImageSoft is that technical support is responsive and knowledgable. I haven't seen too many comments that way about Zortech---although it's nice that Walter Bright follows this group. My current thoughts are: Zortech for playing around with this stuff in MSDOS; Glockenspiel for commercial development. In between? depends on how much they pay you 8-) -- Michael Schwartz ncar!dinl!schwartz mschwartz@mmc.com MSchwartz@Dockmaster.ARPA
daniel@avsd.UUCP (Daniel Edelson) (09/16/89)
In article <657@windy.dsir.govt.nz> SRWMRBD@windy.dsir.govt.nz (ROBERT) writes: >>Joe English writes >>Zortech sells a good C++ compiler for MS-DOS at... >>...but it does support everything in The Book. >It is a good product but it doesn't support everything in The Book. >For example, don't expect user defined conversion operators to work >and do expect some expressions to mis-compile. >Robert Also no pointers to members. No reasonable way to take the address of a member function. And it seems to break in programs with too much data with symptoms being that the __STIxxx routines are not invoked. Still, it seems like a good product at a reasonable price for many uses. daniel
daniel@avsd.UUCP (Daniel Edelson) (09/16/89)
In article <6492@columbia.edu> kearns@read.UUCP () writes: > >I would recommend AGAINST going with Zortech... > >The best product I have found is the Glockespiel 1.2E1 version of the >AT&T translator.... built ontop of the microsoft C5.1 compiler. >-steve Being able to use the Microsoft libraries is an advantage, in fact a compelling one for us because we use Informix' C-ISAM product, which requires the Microsoft *4.0* libraries. However another two advantages to the Zortech product over the Glockenspiel/Microsoft route are 1) the price, and 2) the fact that the Glockenspiel linker has about 127 significant characters in identifiers while Microsoft supports 31. We use grossly long identifier names that differ only in the last few characters, and these are nested 3 or 4 classes deep. 31 Character identifiers created a real headache for us, requiring a preprocessing stage before compilation to shorten identifiers using sed. daniel edelson daniel@saturn.ucsc.edu
sho@maxwell.physics.purdue.edu (Sho Kuwamoto) (09/17/89)
In article <2053@avsd.UUCP> daniel@avsd.UUCP (Daniel Edelson) writes: >In article <657@windy.dsir.govt.nz> SRWMRBD@windy.dsir.govt.nz (ROBERT) writes: >>>Joe English writes >>>Zortech sells a good C++ compiler for MS-DOS at... >>>...but it does support everything in The Book. >>[...] >Also no pointers to members. No reasonable way to take the address of a >member function. [...] So, what does (or should) it mean to take the address of a non static member function? -Sho -- sho@physics.purdue.edu <<-- just wonderin.
awd@dbase.UUCP (Alastair Dallas) (09/18/89)
In article <293@softeng1.UUCP>, root@softeng1.UUCP (Lyle Zumbach) writes: > What C++ translators/compilers are available for DOS or OS/2? > Is Microsoft marketing a C++ product? > When will Microsoft or Borland be selling a C++ 2.0 compiler? You're in luck--an excellent native code C++ (<2.0) compiler is available from Zortech. The code speed and size efficiency are legendary, and the product is comparable to Microsoft's Quick C or Borland's Turbo C in completeness and out-of-the-box usability. I have a copy in front of me that I haven't had time to even install (more's the pity). Hopefully your mail will generate more Zortech testimonials from people who've actually used the product, because the author, Walter Bright, is a regular in this newsgroup. /alastair/ Zortech, Inc. 366 Massachusetts Avenue Arlington, MA 02174 (617) 646-6703 Disclaimer: My employer bought the software in question, but I'm speaking for myself only.
mark@intek01.UUCP (Mark McWiggins) (09/19/89)
In article <661@windy.dsir.govt.nz>, SRWMRBD@windy.dsir.govt.nz (ROBERT) writes: > > Someone who reads this news group wrote saying they were working on > a 386 compiler. Maybe they should report progress. We've been shipping an 80386 DOS C++ for several months. It's currently based on AT&T 1.2, to be 2.0ized soooon. -- 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++!
dspoon@ncratl.Atlanta.NCR.COM (Dave Witherspoon) (09/20/89)
In article <236@dbase.UUCP>, awd@dbase.UUCP (Alastair Dallas) writes: > In article <293@softeng1.UUCP>, root@softeng1.UUCP (Lyle Zumbach) writes: > > What C++ translators/compilers are available for DOS or OS/2? > > Is Microsoft marketing a C++ product? > > When will Microsoft or Borland be selling a C++ 2.0 compiler? > > You're in luck--an excellent native code C++ (<2.0) compiler is available > from Zortech. The code speed and size efficiency are legendary, and the > product is comparable to Microsoft's Quick C or Borland's Turbo C in > completeness and out-of-the-box usability. I have a copy in front of me > that I haven't had time to even install (more's the pity). Hopefully > your mail will generate more Zortech testimonials from people who've > actually used the product, because the author, Walter Bright, is a > regular in this newsgroup. > > /alastair/ OK. I'll play my tune. We've been using Zortech's C++ compiler for better than a year now. Earlier versions had some problems, but Walter's been very responsive to problem fixing. The most admirable trait about Zortech in general has been Walter's firm stance against vaporware. Although I have not received a new version (2.0), I understand that it is in the final stages of beta-test. I have every confidence that Walter has a truely remarkable product on the verge of going out the door. We started out using Advantage's C++ (from Glock), but we had some code that the thing just couldn't compile. It generated names that were not unique within 31 characters, so MSC 5.0 complained. Naturally, I contacted Glock..."tough noogies" was what I was told, with no promise of repair in the future. I have access to Walter Bright and Zortech's support staff here, on BIX, and elsewhere. By the way, ZTC compiled that "problem code" first time. Now that I've gotten used to Zortech's debugger, I don't think I want to go back to CodeView! And I'm incredibly anxious to see what has become of the debugger in the next release...I understand that it will be an object-level debugger. Finally, it's true that 1.07 has some bugs. Some are serious. We are told that the next release will be well worth the wait for the bug fixes and everything else that's coming with that version. From what I've seen so far, I have no reason to doubt that. True, Borland is coming out with a C++ compiler. My guess is that they will be where Zortech was over a year ago with their first release. I owe Zortech nothing...just a satisfied user/abuser. -------------------------------David Witherspoon------------------------------- D.Witherspoon@Atlanta.NCR.COM | "Dolphins find humans amusing, but NCR Retail Systems Development/Atlanta| they don't want to talk to them." MY OPINIONS...ALL MINE!!! | - David Byrne
kearns@moritz.columbia.edu (Steve Kearns) (09/21/89)
Hi. Here is a nifty trick I use to get around the problem of translators that generate names which are not unique in the first 32 characters. If your class is called "BigString", then at the top of your BigString.h file put "#define BigString bS" This makes the internal name of BigString the much shorter name bS and has always solved my problems. -steve
SRWMRBD@windy.dsir.govt.nz (ROBERT) (09/21/89)
In article <1456@dinl.mmc.UUCP>, schwartz@dinl.uucp (Michael Schwartz) writes: > Glockenspiel has done a good job in 1.2E1 of > a) rolling out low memory used by make and the front end to > effectively add about 84K of DOS memory--enough for hierarchies > that are not too deep I haven't found this very satisfactory; I still need to use a batch file and avoid 'make' to do my big files. If you use this roll out mechanism compile times can rise amazingly - say from 100 seconds to 2000 seconds. > My current thoughts are: Zortech for playing around with this stuff in > MSDOS; Glockenspiel for commercial development. In between? depends on > how much they pay you 8-) I more-or-less agree; however I wonder whether commercial development on a PC using C++ is sensible. There is quite a large cost in code file length (I hope to document this some time); my experience with the earlier versions of Glockenspiel has been a bit unhappy, particularly in dealing with both Lifeboat and Oasys as agents - I think at least half the problem was Glockenspiel's; Glockenspiel still has limitations (eg in length of names it can handle and see my bug report of some time ago and it inherits at least one bug from MsC 5.1 precluding the use of float); and the programming environment is in the dark ages. Now if Walter Bright would sort out Zortech C++ .....
hansen@pegasus.ATT.COM (Tony L. Hansen) (09/22/89)
< I haven't found this very satisfactory; I still need to use a batch file < and avoid 'make' to do my big files. If you use this roll out mechanism < compile times can rise amazingly - say from 100 seconds to 2000 seconds. When I use one of the cfront ports under DOS, I found this small trick useful. Because cfront can run out of memory so easily, even using make can push things over the limit. So instead of running make directly to build things, I run it indirectly via a small batch file: mk.bat make -n %1 %2 %3 %4 %5 %6 %7 %8 %9 > tmp.bat tmp The "make -n" will run through all of its checks and print out exactly what it would have done to build your process, creating another batch file which then gets run to do the actual compilation. Doing things this way permits you to compile your programs with nothing but command.com running, yet still being able to take full advantage of make's powers. I hope that this can save someone somewhere some time waiting on those long compiles! Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com
dspoon@ncratl.Atlanta.NCR.COM (Dave Witherspoon) (09/23/89)
In article <6505@columbia.edu>, kearns@moritz.columbia.edu (Steve Kearns) writes: > Here is a nifty trick I use to get around the problem of > translators that generate names which are not unique in the first > 32 characters. > > If your class is called "BigString", then at the top of your > BigString.h file put > "#define BigString bS" > > This makes the internal name of BigString the much shorter name bS > and has always solved my problems. Thanks for the tip, Steve. You may be posting this when you saw my post on the problems I had with Glockenspiel's C++ translator. The problem I had had to do with overloading operator<< for an ostream. The names were almost completely out of my control, so I'm not sure that your trick would have helped me back then. In any case, I refuse to kluge around compiler problems that are 2 levels away (i.e., in the translator, once removed from the compiler). -------------------------------David Witherspoon------------------------------- D.Witherspoon@Atlanta.NCR.COM | "Dolphins find humans amusing, but NCR Retail Systems Development/Atlanta| they don't want to talk to them." MY OPINIONS...ALL MINE!!! | - David Byrne
kneller@cgl.ucsf.edu (Don Kneller) (09/25/89)
hansen@pegasus.ATT.COM (Tony L. Hansen) writes: >< I haven't found this very satisfactory; I still need to use a batch file >< and avoid 'make' to do my big files. If you use this roll out mechanism >< compile times can rise amazingly - say from 100 seconds to 2000 seconds. >When I use one of the cfront ports under DOS, I found this small trick >useful. Because cfront can run out of memory so easily, even using make can >push things over the limit. So instead of running make directly to build >things, I run it indirectly via a small batch file: >mk.bat > make -n %1 %2 %3 %4 %5 %6 %7 %8 %9 > tmp.bat > tmp The disadvantage of this technique is that "mk.bat" won't stop if a compiler error happens. At the risk of sounding like a plug, my OPUS MAKE program swaps itself from memory before spawning its shell lines, reducing its memory requirements to about 3K. I can supply more information to anyone who is interested. - Don Kneller OPUS Software (415) 664-7901 ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller INTERNET: kneller@cgl.ucsf.edu
hansen@pegasus.ATT.COM (Tony L. Hansen) (09/26/89)
<< When I use one of the cfront ports under DOS, I found this small trick
<< useful. Because cfront can run out of memory so easily, even using make
<< can push things over the limit. So instead of running make directly to
<< build things, I run it indirectly via a small batch file:
<<mk.bat
<< make -n %1 %2 %3 %4 %5 %6 %7 %8 %9 > tmp.bat
<< tmp
< The disadvantage of this technique is that "mk.bat" won't stop if a
< compiler error happens.
Quite true. I'd forgotten that I handled that as well. (I didn't have my DOS
machine handy at the time I wrote the previous message. Sigh. I really
dislike using extra bandwidth.)
The real mk.bat file has one additional line in it:
mk.bat:
make -n %1 %2 %3 %4 %5 %6 %7 %8 %9 > tmp.bat
ed - tmp.bat < c:\xbin\tmpmak.ed
tmp
ed is the old standby; I use MKS's version. The script tmpmak.ed is simple;
it adds "if" tests after each line plus an ":error" label at the end:
tmpmak.ed:
H
g/^/a\
if errorlevel 1 goto error
.
$a
:error
.
w
q
I'm certain that similar things can be done with other line editors, such as
edlin. A simple C program could also be used.
adderror.c:
#include <stdio.h>
main()
{
char buf[1024];
while (fgets(buf, sizeof buf, stdin)) {
fputs(buf, stdout);
fputs("if errorlevel 1 goto error\n", stdout);
}
fputs(":error\n", stdout);
return 0;
}
and mk.bat becomes
mkbat:
make -n %1 %2 %3 %4 %5 %6 %7 %8 %9 > tmp.bat
adderror < tmp.bat > tmp2.bat
tmp2
< At the risk of sounding like a plug, my OPUS MAKE program swaps itself
< from memory before spawning its shell lines, reducing its memory
< requirements to about 3K. I can supply more information to anyone who is
< interested.
Unfortunately, I've had occasions where even 3K made a difference. The
mk.bat scheme requires NO memory overhead besides DOS and command.com.
(Other than that, your make program sounds great.)
Tony Hansen
att!pegasus!hansen, attmail!tony
hansen@pegasus.att.com