Path: utzoo!attcan!uunet!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Anyone doing a G++ port of ET++ v2.0?
Message-ID: <2336@lupine.NCD.COM>
Date: 29 Oct 90 19:00:08 GMT
References: <314@unf7.UUCP>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 55

In article <314@unf7.UUCP> shite@unf7.UUCP (Stephen Hite) writes:
<
<   Just wondering if anyone is motivated to do a G++ port of ET++ v2.0?
<I'm interested in doing a port of ET++ v2.0 to Interactive Unix v2.2.
<I have Comeau's port of C++ 2.0 so that shouldn't be the barrier.  I 
<have G++ up on my system and if someone has done the port on a Sun then
<I could start fresh with the G++ diffs.

I'm working on it as we speak.

Nobody's paying me for it however, so I make no commitments regarding
completion.

So far I have at least gotten the `utils', `sunfonts', `xfonts', `src',
and `applications' directories to build.  This took a bit of doing because
(apparently... and not suprizingly to this writer) cfront 2.0 allowed a few
illegalities slip by.  In particular:

	Contrary to the author's assertions, there were still some
	(anachronistic) assignments to `this'.  g++ didn't like these
	at all.

	cfront 2.0 apparently doesn't mind if the last thing in a
	parameter list is a comma!

	cfront 2.0 apparently either provides default constructors when
	it shouldn't or else it simply fails to enforce the rule that 
	the mem-initializer list for a constructor of a derived class
	must include an explicit mem-initializer for any base class which
	has no default constructor.  g++ insisted (quite rightly in my
	opinion) on this point.

	cfront 2.0 apparently does not insist that the return type of
	a member function in a derived class should exactly match the
	return type for the function it overloads (if there is one)
	in the base class.  Again, g++ insisted on this (quite correctly).

Other problems arose because of disagreements between ET++ and the include
files of libg++ about such things as the proper profiles of bcopy, bcmp,
bzero, index, rindex, and alloca, and disagreements about where the various
flavors of abs() should be declared/defined.

(The points above should not be interpreted to mean that g++ is necessarily
better or worse than cfront.  If the situation were reversed, and if I was
porting something which was initially developed with g++ to cfront, I would
just have a different list of illegalities that g++ had missed.)

I will post my ET++ patches as soon as I can get most of the applications
to run without segfaulting.  (Right now they all segfault.)

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.