Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!milano!cadillac!vaughan@mcc.com
From: vaughan@mcc.com (Paul Vaughan)
Newsgroups: comp.lang.c++
Subject: Re: Should we use C++?
Message-ID: <3280@cadillac.CAD.MCC.COM>
Date: 13 Oct 89 16:07:47 GMT
References: <17898@rphroy.UUCP> <2211@cbnewsl.ATT.COM>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: vaughan@mcc.com (Paul Vaughan)
Organization: MCC VLSI CAD Program
Lines: 32
In-reply-to: dog@cbnewsl.ATT.COM (edward.n.schiebel)


	Don't expect to use gnu g++ 1.35.x for work involving multiple
inheritance.  There are also other 2.0 'isms that g++ 1.35 will not
handle.  There is a prerelease of g++ 1.36 available that has been
sufficient to support my uses of multiple inheritance, but the
official g++ 1.36 has not yet been released.  My experience with a
slightly out-of-date prerelease of 1.36 is that virtual base classes
do not work.  I've noticed that the prerelease fixes a few 2.0 'isms
that 1.35 didn't handle, but I certainly haven't tested it
exhaustively.
	This is a slightly different topic, but it might be valuable
info.  I have been mixing 1.35 compiled code with 1.36.0- compiled
code without difficulty.  I've had to do this because the InterViews
library cannot be compiled with 1.36 (it is still 1.2 compatible,
after all).  I sometimes swap back and forth between compilers because
the "other" one sometimes gives better error messages before crashing.
I compile anything that involves MI with 1.36.0-.  The one problem I
have had with linking code from the two compilers is that I have to be
sure to declare any 1.35 compiled functions to be overloaded before I
can use them in the 1.36 code.  This is only a problem for ordinary
(non-member) functions though.  I have unresolved problems when
InterViews .h files include inline function definitions that have 1.2
'isms in them (such as assigning to "this").  I suspect I will have to
modify the library code, if the InterViews crew doesn't do it for me.
	Take this message in perspective.  That is, at the moment, the
official g++ release is not up to MI.  It probably will be soon.  It
seems that ATT leapfrogged FSF in quality assurance this time, but
that isn't too surprising considering they were writing the spec and
FSF could only guess.

 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan