Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!elan!tom
From: tom@elan.elan.com (Tom Smith)
Newsgroups: comp.lang.c++
Subject: Re: problems in cfront 2.0 with +e[0|1] options and __ptbl__...
Message-ID: <686@elan.elan.com>
Date: 15 Jan 90 19:41:36 GMT
References: <1379@mit-amt.MEDIA.MIT.EDU>
Organization: Elan Computer Group, Inc., Mountain View, CA
Lines: 30

From article <1379@mit-amt.MEDIA.MIT.EDU>, by peter@mit-amt.MEDIA.MIT.EDU (Peter Schroeder):

> // I am running cfront 2.0 and have a problem with the +e[0|1] option.
> // Is it a bug?
    [ description of +e[0|1] argument behavior for optimizing virtual
      function table instance declarations ]

> // What I generally do is that I compile all files in my system with +e0, but
> // one special file (which I call `vtbl.C'), which only contains `#include's
> // for all header files which have virtual functions. So far this never
> // caused a problem. This is my first use of a pure virtual and that broke
> // it.

I once determined that in a 1.2M executable built with C++ 1.2 from
Glockenspeil, over 100K was taken up by extraneous virtual function 
table instances.  In that particular application, using the +e
arguments was impractical because the product was a set of libraries;
one could not determine until link-time which class definitions and
table instances were required.

I remember reading somewhere that the C++ 2.0 implementation was
going to generate the virtual function table for a given class
in the file that implemented the first virtual member function for
that class, and all other files would be external declarations.
Checking out the generated C from my copy of C++ 2.0 from Sun,
this does not appear to be the case.  What ever happened to this plan?

    Thomas Smith
    Elan Computer Group, Inc.
    tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom