whm@sunquest.UUCP (Bill Mitchell) (10/27/88)
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
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (10/28/88)
They apparently have a couple of warring political factions there (what company doesn't), like the founding "Pascalites" and the newly-hired "Wave-of-the-Futurites". I've heard that there has been a lot of attrition in the latter group lately, including the manager in charge of the C++ effort, so it may be that they don't understand the C++ marketplace as well as they once did. :::::: Software Productivity Technologies -- Experiment Manager Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::