Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!taumet!mike From: mike@taumet.com (Michael S. Ball) Newsgroups: comp.lang.c++ Subject: Re: C++ and the DEC Station Message-ID: <704@taumet.com> Date: 3 May 91 17:33:38 GMT References: <2608@otc.otca.oz> <1991Apr25.183306.767@rathe.cs.umn.edu> Reply-To: mike@taumet.UUCP (Michael S. Ball) Organization: Taumetric Corporation, San Diego Lines: 25 In article sys1@imdpy1.im.se (Systecon) writes: > >I could defenately not recommend Oregon C++. It is very buggy. I have only >used it on a Sun 3, so I only know of that imlementation, but... I also once >bought the Glockenspiel compiler for SCO Unix, but returned it without opening >it because it hadn't got a source level debugger (it had none at all actually). Then you should try Oregon C++ again. They recently had us take over their maintenance for them, and we are releasing stability updates to all of their compilers. We have found the new version, at least, to have far fewer bugs than cfront, and a lot less "Sorry, not implemented" messages as well. The original 1.2 compiler got an undeserved reputation for being buggy because it attempted to introduce 2.0 features (and restrictions) before 2.0 from AT&T came out. Users assumed anything not like cfront 1.2 was a bug. It did have bugs, but most of the complaints were about differences in features, which the user, not having access to the draft 2.0 reference manual, assumed were bugs. (This is from a recent review of their bug reports.) A major tactical error, in my opinion. Actually, it's academic at the moment since the DECStation version is due to reach field test next week, so you can't buy it. -- Michael S. Ball mike@taumet.com TauMetric Corporation (619)697-7607