🚀 go-pugleaf

> Date: Mon, 7 Sep 92 15:13:52 +0200
> Message-Id: <9209071313.AA03475@larsen.chorus.fr>
> From: ev@chorus.fr (Eric Valette)
> To: bug-g++@prep.ai.mit.edu
> Cc: mrs@cygnus.com

> >This behavior is under consideration by the ANSI C++ committee, they
> >are thinking about defining things such that new should never return
> >0.  It would throw an exception instead.  This has long been recognized
> >by g++ as the proper way to do things, and hence its past and current
> >behavior.
> >
> >I am inclided not to consider this a bug, until ANSI C++ decides it is.
> >
> >For now, I would recommend that you try and code your software in such
> >a way that it will work or be easy to change, either way ANSI decides.
> >
> >As a practical matter, you can do something like:
> >
> >  p = (void *) malloc (sz);
> >  if (p == 0)
> >    (*__new_handler) ();
> >  return p;


> Enough! I have seen this bug reported since G++ 1.37.2. I do not want
> to protect EACH constructor by code like:

> 	if (this == 0)
> 		return;

In the long run, you will not have to do this.

> nor do I want do use setjump/longjump to avoid going into the
> constructor.  I know (as operating system writter) that many people
> use C++ to write embedded system where they redefine operator new
> for each class as a poll allocator. It is not because a pool
> allocator fails that you must stop your application and thus control
> must be given to user. A *very* simple way is to return zero and let
> the user decide what to do.

A *very* simple way to do this with a real C++ compiler is to throw an
exception.  I know, g++ in this sense is not a real compiler, but one
day, it will have exceptions.  In fact that is the way ANSI seems to
be going, and THAT (the ISO/ANSI C++ standard) *IS* going to be the
standard for C++, not cfront, I think.

> 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

> I am amazed you use ARM to argue because it is clear that people
> never read it before implementing G++.

I hate to say it, but g++ has been around longer than the ARM, but I
am sure you knew that.  Also, C++ as a langauge has been undergoing
many changes and revisiosns since it was first introduced.  It is our
goal to track and follow ANSI and ISO C++ as the reference for the C++
language, I am not sure why this fact amazing.

> In particular, some people shoulkd have read it before implementing
> MI to understand impact on virtual functions...

I think the problem was more of the, g++ had single inheritance before
it had MI.  g++ was implemented before there was MI.

If you know of some base design mistakes that make implemented correct
MI behavior impossible, please let me know.  Also, if you know of MI
bugs that have not beem reported before, please report them, as I have
weeks worth of engineering time devoted to this topic.

> 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.

Well, I know many different camps using gcc to compile kernels.  OSF
is, NeXT is, and BSD is.  You fail to mention what the problem
compiling was.  Is it that Chorous is not portable, is it that gcc
incorrectly implements the ANSI C language, is it that you are dealing
with a bad port of gcc, or maybe you meant g++ above, I cannot tell.