Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!amdcad!ames!mailrus!ncar!noao!arizona!sunquest!whm
From: whm@sunquest.UUCP (Bill Mitchell)
Newsgroups: comp.lang.c++
Subject: Oregon C++ -- the saga continues
Message-ID: <153@sunquest.UUCP>
Date: 26 Oct 88 20:14:27 GMT
Article-I.D.: sunquest.153
References: <247@oresoft.UUCP>
Organization: Sunquest Information Systems, Tucson
Lines: 40

At the Denver C++ conference I had the opportunity to speak with several
persons from Oregon Software, and Michael Ball from TauMetric, concerning my
problem with the Oregon C++ system.  I was greatly encouraged by my
conversation with Michael Ball, the author of the compiler, but I was
discouraged by my conversation with the folks from Oregon Software itself.

Basically, I haven't yet found anyone outside of Oregon SW that thinks it's
unreasonable to want to use Oregon's C++ compiler with OS-vendor libraries,
and I haven't yet found anyone who works for Oregon that thinks that such
usage should be provided for in their product.

Michael Ball, who (as I understand it) agrees with my position, has said that
he'll send me a list of routines that comprise the run-time support for
C++.  If Oregon would also supply a library of only the run-time routines and
support the usage of it, they'd meet the needs of both the persons who want
to use the ANSI C libraries and those who want to use OS-vendor C libraries.
I discussed this with two persons from Oregon and both felt that providing and
supporting an additional library presented more of a logistical burden than
could be justified.  Oregon's proposed approach is to simply fix collision
problems as they occur (e.g. via extracting malloc.o and realloc.o to fix
the current problem), but to me, eliminating a class of problems is usually
preferable to fixing instances of a class of problems.

I hope that with Michael's help the current problem can be satisfactorily
resolved, but given all the trouble with this particular problem, I'm now
hesitant to count on Oregon's support.  Maybe the correct thing to do is to
use g++ for development and AT&T C++ for the final product, or maybe just use
g++ all around.  (I have to admit that I've had a much more pleasant experience
with g++ than with Oregon C++.)  On another front, I've recently spoken with
Saber Software and they're talking about Saber-C++.  They say that it's still
in the "twinkle in the eye" phase, but they think they might have a product
by the end of '89 and perhaps some support tools (e.g. a browser) before then.

--------------------------------------------------------------------
Bill Mitchell, Possibly-soon-to-be ex-user of the only commercial UNIX C++
compiler and Source-Level Debugger
					whm@sunquest.com
Sunquest Information Systems		sunquest!whm@arizona.edu
Tucson, AZ 				{arizona,uunet}!sunquest!whm
602-885-7700