shite@unf7.UUCP (Stephen Hite) (10/26/90)
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 planning on using Tom Roell's x11r4 VGA server and libraries. If anyone can send me some war stories on ET++ ports it would be a big help. If not, then I guess I'll go into "battle" alone. :-(. I'm going to fit it into my free time away from graduate assignments so it might be done in late Spring (much sooner, of course, if it's fairly trivial). Thanks in advance for any info! ----------------------------- Steve Hite ...gatech!uflorida!unf7!shite
rfg@NCD.COM (Ron Guilmette) (10/30/90)
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.jfischer@sco.COM (Jonathan A. Fischer) (11/01/90)
In article <2336@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >... cfront 2.0 allowed a few >illegalities slip by. In particular: >... > 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). "Overload" is the wrong word here. The function in the derived class in fact _hides_ the function of the same name in the base class. Overloading only occurs at the same "level". class Base { ... void func( int, int ); }; class Derived: public Base { ... long func( void ); }; is perfectly legal. g++ should accept this.