🚀 go-pugleaf

In article <9209071313.AA03475@larsen.chorus.fr> ev@chorus.FR (Eric Valette) writes:
>FLAME ON
>
>FURTHERMORE THE CFRONT COMPILER DO THINGS OTHERWAY AND AS FAR AS I
>KNOW IT IS *THE* REFERENCE FOR C++ (except for exception :-))
>
>FLAME OFF

No, cfront is not *THE* reference for C++.  The ANSI/ISO C++ committee is
working on the reference.  The base documents for the draft standard are
the ANSI C standard and the ARM.  If cfront (any version) were the
reference, it would be impossible for the cfront compiler to have any
bugs.  I can see it now: Whoops -- it appears that the standard calls for
us to core dump on this input! :-)

It is true that in the absence of exceptions, the current behavior of
g++ can cause problems in some applications.  But it is a rare event
for an allocator to fail to return memory, and exceptions are a far
more efficient and reliable way to handle rare events than having users
test every time for errors.  Precisely because errors are so rare,
users are tempted to omit the checks for them, while exceptions will
be thrown reliably every time and not impose an excessive cost when
allocation succeeds.

Perhaps in the meantime it would be possible to add a switch that, if
given, would insert the test for zero return value from the allocator
before calling the constructor.  I think this would be the best solution.
But this is free software; what that means is that anyone -- including
you -- can make the change, and you can donate it back to the community
so others can have it.  Alternatively, you could hire Cygnus or some other
consultant to make the change for you.

>I am amazed you use ARM to argue because it is clear that people never read
>it before implementing G++.  In particular, some people shoulkd have read it
>before implementing MI to understand impact on virtual functions...

Excuse me?  Look at the publication date on the ARM.  Should Mike Tiemann
have hopped into his time machine, gone into the future, and retrieved
the ARM from the future?  The Cygnus people are doing their best to alter
g++ to conform to the emerging standard.  In this case, you're asking them
to make a change that goes in the opposite direction.

>Frankly spealing I use all other GNU stuff (gemacs(1.55.1), gdb (4.5), 
>gcc (2.2.2) but G++ is far to have the quality of other GNU tools : 
>I never manged to compile the chorus kernel with 
>GCC 2.x nor G++ 1.40. 

Then submit bug reports, giving the preprocessor output and the output
of "gcc -v", so the maintainers can reproduce your problems and correct
them.




--
Joe Buck	jbuck@ohm.berkeley.edu