HDTenEightyP/NetNews huggingface dataset:
From: lewis@sophists.COM (Lewis G. Pringle)
Subject: g++ 2.2.1 bug with overloading
Reply-To: lewis@sophists.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 00:40:00 GMT

// This code compiles fine when ShowBug is 0, but if set to 1, then we get the
// error message:
//	fred.cc: In function `void  Normalize (const struct String&)':
//	fred.cc:42: assignment not defined for type `CircularArrayNodeOfString'
// compiling using:
//	g++ -c fred.cc; with gcc 2.2.1
//
// According to ARM 12.8 (page 295) [refering to assignment operators and
// copy constructors] "The programmer may define one or both of these. If not
// defined by the programmer, they will be defined as memberwise assignment and
// memberwise initialization of the members of X, respectively"
//
// Given this definition, how overloading takes place should not be effected
// by whether or not I define this operator. That is the first bug. Secondly,
// The line 42 below which fails to compile (when ShowBug is 1) should compile
// correctly because it involves only 1 user-defined conversion (String->CircularArrayNodeOfString).



#define	ShowBug	1
struct	String {
	String (const String& from);
	~String ();

 	String&	operator= (const String& newString);
};

struct	CircularArrayNodeOfString    { 
	CircularArrayNodeOfString  (String item): fItem (item)	{}
	~CircularArrayNodeOfString ()				{}
#if	!ShowBug
	CircularArrayNodeOfString&	operator= (const CircularArrayNodeOfString&);
#endif
	String	fItem;
};

void	Normalize (const String& a)
{
	CircularArrayNodeOfString aa (a);

	aa = CircularArrayNodeOfString (a);	// works fine
/*42*/	aa = a;					// should involve just 1 user-defined conversion, and be OK?
}


Newsgroups: gnu.g++.bug
From: ev@chorus.FR (Eric Valette)
Subject: Re:  g++ 2.2.2 runs constructor even if operator new() returns 0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 17:13:52 GMT

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

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.

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++.  In particular, some people shoulkd have read it
before implementing MI to understand impact on virtual functions...

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. 

Otherwyse, I would be glad to propose FSF stuff to univercity.

I speak for my own ...


   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Chorus Systemes
(___, / (_(_(__         	6 avenue Gustave Eiffel
				F-78182, St-Quentin-en-Yvelines-Cedex

Tel: +33 (1) 30 64 82 00	Fax: +33 (1) 30 57 00 66
E-mail: ev@chorus.fr
From: dak@pool.INformatik.rwth-aachen.DE
Newsgroups: gnu.g++.bug
Subject: (none)
Date: 11 Sep 92 18:06:00 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Subject: g++-2.2.2 template constants work not in asm statements
The following will bomb the cc1plus with signal 6 (no line numbers given)
when FAULTY is defined. It will work with an instruction replacing the
asm, even with templates.

#ifdef FAULTY
template <const unsigned k>
#else
const unsigned k=300;
#endif

class modular {
public:
unsigned value;
modular(unsigned u=0)
{
	value = u;
}

modular operator *(const modular &b)
{
unsigned __u;
asm("mull %2; divl %3" : "=d" (__u) : "&a" (value)
, "g" (b.value) , "g" (k));
return modular(__u);
}
};

main()
{
#ifdef FAULTY
	typedef modular<300> mod3;
#else
	typedef modular mod3;
#endif
	mod3 gurke(3U), heinz;

	heinz = gurke * mod3(200U);
	return 0;
}
Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ 2.2.2 gets internal error--unrecognizable insn
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 21:38:46 GMT

The error is correct I believe, the core dump is not.

The core dump problem should not exist in the next release of gcc.

> Message-Id: <ROB.92Jul28090211@leopard.cs.man.ac.uk>
> From: rob@cs.man.ac.uk (Robert Marshall)
> To: bug-g++@prep.ai.mit.edu
> Date: 28 Jul 92 08:02:11 GMT
> Reply-To: rajm@cs.man.ac.uk
> Organization: Department of Computer Science, University of Manchester

> leopard-robert-39>gcc-new -v insn.bug.cc
> Reading specs from /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/specs
> gcc version 2.2.2
>  /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix insn.bug.cc /usr/tmp/cca01999.i
> GNU CPP version 2.2.2 (sparc)
>  /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/cc1plus /usr/tmp/cca01999.i -quiet -dumpbase insn.bug.cc -version -o /usr/tmp/cca01999.s
> GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
> insn.bug.cc: In method `a_decl::a_decl (class e_decl*)':
> insn.bug.cc:27: address of `this' not available
> insn.bug.cc:28: internal error--unrecognizable insn:
> (insn 17 16 19 (set (reg:SI 69)
>        (plus:SI (mem:SI (plus:SI (reg:SI 30)
>                    (const_int 68)))
>            (const_int 1))) -1 (nil)
>    (nil))
> gcc-new: Internal compiler error: program cc1plus got fatal signal 6

> This is insn.bug.cc:
> //------------------------------------------------------------------
> class e_decl;
> class a_decl;
> typedef a_decl* a_ref;

> class a_s {
> public:
>                         a_s();
>   void*                   append(a_ref& item);
> };
> class a_decl {
>  public:
>   a_decl (e_decl *parent);
>   a_s  generic_s;
>   a_s       decls;
>   e_decl*        parent;
> };

> class e_decl {
> public:
>   e_decl();
>   a_s implementations;
> };

> a_decl::a_decl(e_decl *parent) 
> {
> 	  parent->implementations.append(this);
> }

Newsgroups: gnu.g++.bug
From: jorgnsn@qucis.queensu.ca (John Jorgensen)
Subject: operator new with placement
Organization: Computing & Information Science, Queen's University at Kingston
Distribution: gnu
Date: Mon, 14 Sep 1992 21:26:40 GMT

Are there any known problems with g++ 2.2.2's handling of the new operator
when it is given an explicit placement option?  While trying to understand
a problem g++ was having with the output of a code generator, I tried
it on the following trivial example of explicit placement, simplified
from Stanley Lippman's "C++ Primer, Second Edition": 

    // example of placement argument to new, taken from Lippmann, "C++ Primer".

    #include <iostream.h>
    #include <new.h>

    class Foo {
    public:
	int val;
	Foo() {val = 0;}
    };

    char *buf = new char[sizeof(Foo)];

    main() {
	Foo *pb = new ((void *)buf) Foo;

	// check that objects were placed in buf.
	if ( (char*)pb == buf)
	    cout << "Operator new worked!: pb: " << pb << " buf: " << (void*)buf << endl;

	return 0;
    }

This works with our copy of AT&T C++ 3.0, but g++ gets a syntax error:

    g++ -v -o new new.c
    Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
    gcc version 2.2.2
     /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix new.c /usr/tmp/cca00711.i
     GNU CPP version 2.2.2 (sparc)
      /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca00711.i -quiet -dumpbase new.cc -version -o /usr/tmp/cca00711.s
      GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
      new.c: In function `int  main ()':
      new.c:15: parse error before `('

I am doing something dumb?  Is there a workaround?

Thanks.
-- 

John Jorgensen		jorgnsn@qucis.queensu.ca	(613) 545 6784
Systems Programmer, Dept. of Computing Science, Queen's University

Newsgroups: gnu.g++.bug
From: spl@szechuan.UUCP (Steve Lamont)
Subject: libg++ 2.2 dies in installation step on Sun 4/370 running 4.1.1
Organization: University of Calif., San Diego/Microscopy and Imaging Resource
Distribution: gnu
Date: Sun, 6 Sep 1992 01:00:04 GMT

I'm not sure whether this is a bug or simply a botched installation,
hence the crosspost.  Forgive me if I'm not following protocol:  I
don't normally read these two groups.

I'm experiencing the following problem when installing libg++ 2.2
using gcc/g++ 2.2.2 as the result of typing 

	make install

Things go along fine until...

---- begin extract of transcript ----
cd test-install; make test-90S \
    CC=/usr/local/bin/gcc COMPILE_FLAGS="" LIBS=-lg++
/usr/local/bin/gcc   -c foo_main.cc
/usr/local/bin/gcc   -c foo_func.cc
/usr/local/bin/gcc   -c Foo.cc
/usr/local/bin/gcc -g -v -o foo_main.run  foo_main.o foo_func.o Foo.o -lg++
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 ld -e start -dc -dp -o foo_main.run /lib/crt0.o \
	-L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2 \
	-L/usr/local/lib foo_main.o foo_func.o Foo.o -lg++ -lgcc -lc -lg -lgcc
./foo_main.run > foo_main.out
foo_main.cc:32: failed assertion `Foo::nb_foos() == 2'
sh: 1013 Abort - core dumped
*** Error code 134
make: Fatal error: Command failed for target `foo_main.out'
Current working directory /p0/spl/gnu/libg++-2.2/libg++/test-install
*** Error code 1
make: Fatal error: Command failed for target `install'
Current working directory /p0/spl/gnu/libg++-2.2/libg++
*** Error code 1
make: Fatal error: Command failed for target `install-libg++'
---- end extract of transcript -----

Have I managed to botch something in either the compiler build or the
library build?  Unfortunately, I'm not a c++/g++ programmer (yet --
that's the reason for installing this -- so I can learn g++) so I'm
not able to tell whether the compiler is botching things, the library
is hosed, or I've managed to screw something up in the installation.
(I'm betting on the latter :-/)

Any guidance that more experienced folks can provide will be
appreciated.

							spl
-- 
Steve Lamont, SciViGuy -- (619) 534-7968 -- spl@dim.ucsd.edu
UCSD Microscopy and Imaging Resource/UCSD Med School/La Jolla, CA 92093-0608
"There was a time when tyrants feared/The new world of the free.
Now freedom is afraid and shrieks/At tyranny." - "Brave New World," A. Macleish
From: rrh@tera.com (Robert R. Henry)
Newsgroups: gnu.g++.bug
Subject: aggregate initialization errors not caught
Date: 6 Sep 92 18:07:35 GMT
Distribution: gnu
Organization: GNUs Not Usenet

For this file, compiled with g++2.2 using ``g++ -Wall cinit.c -c'',
no error message is given.

In fact, this program is seems to be in clear violation of ARM 8.4.1,
which states that ``An aggregate is an array or an object of a class with
... no private or protected members (cf 11), no ...''

  class Thing{
  private:
	  int x,y;
  public:
	  void doit(int);
  };

  Thing t = {18,19};

rrh@tera.com
Newsgroups: gnu.g++.bug
From: dak@pool.INformatik.rwth-aachen.DE
Subject: reference return works not for member references
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Sep 1992 11:51:19 GMT

The following bounces. (BTW, can anyone imagine why
.* and ->* should have lower priority than . and -> ?
It is in ARM but foolish. a pity)

struct V {
	int x;
} X;

typedef int V::* Vptr;

int &test(Vptr y)
{
	return X.*y;		// This produces warning and bad code
	return *&(X.*y);	// Workaround
}
Reading specs from /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -D__unix__ -D__i386__ -D__unix -D__i386 bug.cc /usr/tmp/cca00591.i
GNU CPP version 2.2.2 (80386, ATT syntax)
 /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/cc1plus /usr/tmp/cca00591.i -quiet -dumpbase bug.cc -version -o bug.s
GNU C++ version 2.2.2 (80386, ATT syntax) compiled by GNU C version 2.2.2.
bug.cc: In function `int & test (int (struct V::*))':
bug.cc:9: warning: reference to non-lvalue returned

Newsgroups: gnu.g++.bug
From: pcm@cs.brown.edu (Peter C. McCluskey)
Subject: incorrect vptr offset, MI?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 15:40:52 GMT

#include <stream.h>

The following produces a bus error at the call n->Foo()
on a Sun 4/60. If "virtual ~A(){}" is removed it will
correctly print 12. I think it is using a function address
from a location after the end of the vtable.

class A
{
 public:
  virtual ~A(){}
  virtual int Foo() { return 10; }
};
class B
{
 public:
   virtual int Foo() { return 11; }
};
class C : public A,public B
{
 public:
   virtual int Foo() { return 12; }
};

main()
{
   C* n = new C();
   cout << n->Foo() << endl;
   return 0;
}


kato% g++ -v -c t.cc
Reading specs from /cs/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /cs/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix t.cc /usr/tmp/cca29452.i
GNU CPP version 2.2.2 (sparc)
 /cs/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca29452.i -quiet -dumpbase t.cc -version -o /usr/tmp/cca29452.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
 as -o t.o /usr/tmp/cca29452.s
kato% g++ -o t t.o
kato% t
Bus error

I believe this is the relevent assembly output, produced by:
 g++ -S -O2 t.cc

	ld [%o0+4],%o1
	ldsh [%o1+16],%o2
	add %o0,4,%o0
	ld [%o1+20],%o1
	call %o1,0

Newsgroups: gnu.g++.bug
From: brage@ideal.id.DK (Jens P. Brage)
Newsgroups: gnu.g++.bug
Subject: Problem with class-local enum declarations in g++ 2.2.2
Date: 11 Sep 92 14:06:12 GMT
Reply-To: brage@ideal.id.dk (Jens P. Brage)
Distribution: gnu
Organization: Dept. of Computer Science, Technical University of Denmark

Hi.

I think I've found a bug in g++ 2.2.2: Class-local enumerations cannot be
addressed from within another class:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
class ClassA
{
public:
  enum AnEnumeration { Enum1, Enum2 };
};

ClassA::AnEnumeration Var1;

class ClassB
{
  ClassA::AnEnumeration Var2;
};
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
The declaration of Var1 is accepted, but the declaration of Var2 produces the
error:
> Test.cxx:12: class-local enum declaration `AnEnumeration' is not in scope here

As far as I can see, this should be legal according to r.7.2 of Bjarne
Stroustrup's "The C++ Programming Language". The problem may be related to
another problem with class-local enums I've reported before:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
class ClassA
{
public:
  enum AnEnumeration { Enum1, Enum2 = Enum1 };
};
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
In this case, Enum1 is unknown at the point of declaration of Enum2. This works
if the enumeration isn't embedded in a class.

Version info: I'm running on a Sun Sparc SLC with SunOS 4.1, "g++ -v" gives:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix Test.cxx /usr/tmp/cca16047.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca16047.i -quiet -dumpbase Test.cc -version -o /usr/tmp/cca16047.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

--
Jens P. Brage    (jpb@id.dth.dk)| Between those in constant power and those in
    Design Automation Group     |constant pain. Between those who run to glory
Center of Integrated Electronics|and those who cannot run. Tell me, which ones
Technical University of Denmark |are the cripples and which ones touch the sky?
Newsgroups: gnu.g++.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU C++ 1.41.0 installation report (3)
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 05:45:09 GMT

Let me comment on the installation of GNU C++ 1.41.0, together with
GNU C 1.41, on this 386/ix 2.0.2 system (waiting for Hurd :-).  I will
make these comments in a few bunches.  Here is the third.

The compilation of GNU C++ 1.41 brings a few compiler diagnostics,
which are the subject of this report.

* The following warnings come from the fact that this <stdio.h>
declares _ptr and _base as `unsigned char *' while cplus-tree.h
declares struct pending_inline's buf as `char *':

cplus-lex.c: In function do_pending_inlines:
cplus-lex.c:1307: warning: assignment between incompatible pointer types
cplus-lex.c:1308: warning: assignment between incompatible pointer types
cplus-lex.c: In function yylex:
cplus-lex.c:2731: warning: assignment between incompatible pointer types
cplus-lex.c:2732: warning: assignment between incompatible pointer types

* Maybe NULL should be used as #define'd or else, #undef'ined before
redefinition:

cplus-class.c:39: warning: NULL redefined
cplus-search.c:37: warning: NULL redefined

* The local <stdio.h> does not have a _bufsiz item in struct FILE, but
has "#define _bufsiz(p)	(_bufend(p) - (p)->_base)", so maybe
Z_BUFSIZ(p) could be defined as _bufsiz(p) whenever _bufsiz is
defined:

toplev.c: In function compile_file:
toplev.c:1227: structure has no member named `_bufsiz'
toplev.c:1227: structure has no member named `_bufsiz'
toplev.c:1243: structure has no member named `_bufsiz'
toplev.c:1246: structure has no member named `_bufsiz'
toplev.c:1251: structure has no member named `_bufsiz'

* The line "lang_expand_expr = fancy_abort;" might need a cast:

toplev.c: In function main:
toplev.c:2093: warning: assignment between incompatible pointer types

* File gstab.h exists in GNU C 1.41, but is not linked into g++:

symout.c:35: gstab.h: No such file or directory

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.g++.bug
From: kelly@ipld01.hac.com (Keith Kelly)
Subject: Errors compiling libg++ (v2.2) using g++ (v2.2.2) on Alliant FX/2800
Organization: Hughes Aircraft Company - Canoga Park, CA
              Imaging Guidance Design Laboratory
Distribution: gnu
Date: Fri, 4 Sep 1992 18:50:22 GMT

I'm trying to build the gnu libg++ (version 2.2) library using the gnu g++
(version 2.2.2) compiler on an Alliant FX/2800.  Whenever it tries to
compile any routine with the va_start function, it complains with:

warning: implicit declaration of function `__builtin_args_info'

The libg++ library eventually builds but it has unresolved references to
__builtin_args_info.  The va-i860.h references this function in the va_start
routine but it is unclear where this function is actually defined.  Any
suggestions?  Thanks in advance.

          
-- 
Keith Kelly                    Internet   : kelly@ipla01.hac.com         
"Of all the things I've lost   UUCP       : ...!usc!!hacgate!ipla01!kelly
 I miss my mind the most"      Phone      : (818) 702-2328

Newsgroups: gnu.g++.bug
From: jbuck@forney.berkeley.edu (Joe Buck)
Subject: Re:  g++ 2.2.2 runs constructor even if operator new() returns 0
Organization: U. C. Berkeley
Distribution: gnu
Date: Tue, 8 Sep 1992 17:10:37 GMT

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

Newsgroups: gnu.g++.bug