Topic: disaster in GNU g++ 2.5.7 (virtual base classes)


Author: burli@infotech.tu-chemnitz.de (Bernd Fankhaenel)
Date: 14 Jan 94 12:45:14 GMT
Raw View
/* Hallo, who can help ?, disaster in GNU g++ 2.5.7!!!

Through working with GNU-Compiler V2.4.5 and V2.5.7 we believe that the g++
compiler contains bugs on a very hot point.
Since half a year we continue posting bug mails to gnu bug mail addresses
but no answers reached us.
Please help us!
Help us to convince the GNU compiler specialists to correct the compiler
or please open our eyes to find our mistake understanding the C++ language!

----------------------------------------------------------------------------

Please see the following simple source example and show also the noted
aspects behind: */

class Base {
public:
  Base(){}
  virtual ~Base(){}
};

class A : virtual public Base {
public:
  A(){}
  virtual ~A(){}
};

class B : virtual public Base {
public:
  B(){}
  virtual ~B(){}
};

class C : public A, public B {
public:
  C(){}
  virtual ~C(){}
};

class D : public A {
public:
  D(){}
  virtual ~D(){}
};

class E : public C, public D {
public:
  E(){}
  virtual ~E(){}
};

int main()
{
  Base* p;
  A*    pa;
  B*    pb;
  C*    pc;
  D*    pd;
  E*    pe;

  A a;
  B b;
  C c;
  D d;
  E e;

  p = &a;  // some pointer conversion tests
  p = &b;
  p = (A*)&c;
  p = &d;
  p = (D*)&e;

  pa = (D*)pe;
  pa = (C*)pe;

  return 0;
}

/* ----------------------------------------------------------------------

Compiler output:

gnu4.C: In method `E::E()':
gnu4.C:48: cannot convert a pointer of type `E'
gnu4.C:48: to a pointer of type `A'
gnu4.C:48: because `A' is an ambiguous base class
gnu4.C:48: conversion to non-scalar type requested
gnu4.C: In method `E::~E()':
gnu4.C:49: cannot convert a pointer of type `E'
gnu4.C:49: to a pointer of type `A'
gnu4.C:49: because `A' is an ambiguous base class
gnu4.C:49: conversion to non-scalar type requested
gnu4.C: In method `E::E(const E &)':
gnu4.C:50: cannot convert a pointer of type `E'
gnu4.C:50: to a pointer of type `A'
gnu4.C:50: because `A' is an ambiguous base class
gnu4.C:50: cannot convert a pointer of type `E'
gnu4.C:50: to a pointer of type `A'
gnu4.C:50: because `A' is an ambiguous base class
gnu4.C:50: conversion to non-scalar type requested


Notes:

1. Only without using "Base" as virtual base class the compiler accepts the
   class hierarchy.

2. The compiler errors are ejected by the gnu g++ source module "cp-cvt.c".

3. There is no reason (please read Stroustrup) that a pointer conversion
   (automatic or forced) is forbidden for the shown class hierarchy.

4. We know that a conversion directly from 'class E' to 'class A' is not
   possible. A conversion must be specified by shown the conversion way
   (f.i. (A*)(C*) or (A*)(D*) comming from a pointer to 'class E').

5. For persistent tools it is obvious to use a virtual base class as
   representative type for all persistent child classes. In this way all
   persistent objects can be handled polymorph pointing to this base type.
   The virtual used base class "persistent" have to constructed with special
   virtual member functions to reach the origin class type from the
   virtual base class (input/output function, identify function for
   runtime type info constructions and so on).

6. Persistent construction are very important to load and save the heap and
   it's pointing or reference graph (complete or partial) to every kind of
   media. In this way a persistent object can also be use to flow in a media
   from one to an other machine.
   Persistent C++ objects can so be transport information between different
   machines, different compilers and different medias. By using the included
   runtime informations (typed detecting) the flowing objects can automatic
   reach catch handlers on the other side.

7. Since g++ version 2.4.5 the problem was not solved. Only the error
   messages are more complete.

8. The Borland C++ 3.1/4.0 and also the SPARC-Compiler C++ 3.0.1. does
   not show such terrible problems.

9. We are very wondering, why such hard problems not fixed upto now.
   Is there nobody in the world using the full C++ possibilities ?
   Where are the ears and eyes of the C++ freaks ?

Our project:

This time we develope a powerful simulation tool (POSES++) as client/server
application in a heterogenous environment (DOS/UNIX simulation server
connectable via TCP/IP, shared memory or shared files, WINDOWS/NeXTSTEP/MOTIV
clients to control models and server). This tool will be usefull for
model, simulate and !!on-line-control!! for much discret problems like
in process automation. Modelling and simulation is based on high level
petri nets (extended predicate transition nets). Modelling and simulation
is also usefull for communication systems and hardware development (f.i.
parallel hardware).
To model we use a self defined language (C language is a subset of them,
C++ should it be in future). The language combines structure programming
(in future we hope also object oriented programming) with declarative
programming to define the transition rules for the data flow in the high
level petri net models. That's why we are developing a front compiler to
transform the POSES++ language to C++ constuctions.

For this purpose we need a powerful C++ compiler (without such terrible
bugs!!!).

We hope of your help, fast error fixing and early reply from gnu !!!

Due to no reactions to previous mails to the same problem we will post
this help call to all found gnu mail addresses and all net news groups
discussing C++ !!!

Yours sincerely,

Bernd.

=================================================================
Bernd Fankhaenel                |                               |
GPC                             |Tel.: +49 +371 50593           |
Gesellschaft fuer Prozess-      |Fax.: +49 +371 5194 261        |
automation & Consulting mbH     |email:                         |
GERMANY                         |burli@infotech.tu-chemnitz.de  |
Senefelder Strasse 38           |                               |
09126 Chemnitz                  |                               |
=================================================================
*/




Author: larry@austin.ibm.com (Larry L. Buickel)
Date: Fri, 14 Jan 1994 15:30:15 GMT
Raw View
Compiles fine on AIX using xlC ...
Larry B