Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!stl!concurrent!concurrent.co.uk!asc
From: asc@concurrent.co.uk (Andrew Chittenden,ADT)
Newsgroups: comp.lang.c++
Subject: Problems with cfront v2
Message-ID: <968@sl10c.concurrent.co.uk>
Date: 11 Jan 90 08:21:02 GMT
Sender: news@concurrent.co.uk
Reply-To: asc@concurrent.co.uk (Andrew Chittenden,ADT)
Organization: Concurrent Computer Corp (ESDG), Slough, U.K.
Lines: 83

We have recently purchased version 2 of C++ and have managed to
get it ported to our system V.2 UNIX system.  However, we have hit upon
a snag when taking generated C over to our proprietary platform which
did not occur with version 1.2. 

The C compiler on our proprietary platform is fairly ancient and does
not support enumerated types.  It appears that cfront v2 generates enum
statements when the original source contained enums (for an example use
iostream.h).  The generated C doesn't actually use the enums so there is
no requirement to emit them.  With v1.2, cfront did not emit enum
statements.  Has anyone come across this problem and found a fix? 

In addition, we would like to use virtual inheritence with v2.  However,
we have hit upon a snag.  In v 2.0, objects derived from virtual base
class objects contain pointers to the base class objects.  Our objects
will be saved and retrieved from disk.  Such persistent objects cannot
contain pointers, only relative addresses or offsets.

Below is an example based upon the supplied ZooAnimal classes (note we
do not need virtual functions just virtual inheritence) - we have
anotated the style of generated C that we would require. 

The following simple example illustrates the required changes to the
generated C for access to a virtual base class object.

  class ZooAnimal {
        int a;
        // ...
  };
  class Bear : virtual ZooAnimal {
        int b;
      // ...
  };

  class Raccoon : virtual ZooAnimal {};
  class Panda : Raccoon, Bear {};

  static    Raccoon r:
  static    Panda p:

  main()
  {
   ZooAnimal *a = &(ZooAnimal)p;  // A
   ZooAnimal *b = &(ZooAnimal)r;  // B
   return (0);
  }

Currently, lines A and B are generated as:

 __1a = (((struct ZooAnimal *)(& p )-> PZooAnimal));
 __1b = (((struct ZooAnimal *)(& r )-> PZooAnimal));

where PZooAnimal is declared as
    struct ZooAnimal *PZooAnimal;

within each class derived from ZooAnimal.

In the proposed implementation, PZooAnimal would be declared as int,
and lines A and B would be generated as:


    __1a = (struct ZooAnimal *)((char *) &p + p.PZooAnimal);
    __1b = (struct ZooAnimal *)((char *) &r + r.PZooAnimal);

with the PZooAnimal field in each object having been initialized to
the offset of the ZooAnimal object from the start of the derived object.
For simplicity, changes to initialization code are not shown here.

Note that we do not have to worry about virtual functions and the vtbl
pointer  because virtual functions are not permitted within our
application (it is achieved using a bespoke object manager).

Firstly, does anybody know of any reason why such a change is not
feasible?  Secondly, can anybody point us at the areas of cfront that
would require changing to get such C code generated? 

Rgds, Andy Chittenden
- --
             ___________
            / _________/_   |   DOMAIN:     asc@concurrent.co.uk
           /_/________/ /   |   UUCP:       ...!uunet!ukc!concurrent!asc
  Concurrent/__________/    |   Royal Mail: 227 Bath Road
Computer Corporation        |               Slough SL1 4AX, England