(ref.doc)oreilly 061293

From: Randy O'Reilly <[email protected]>
Newsgroups: comp.lang.c++,comp.sys.hp.misc
Subject: cfront (HP?) extern vtable switch (+e[01])
Date: Mon,  6 Dec 1993 10:32:10 -0500
Organization: Doctoral student, Psychology, Carnegie Mellon, Pittsburgh, PA
NNTP-Posting-Host: po5.andrew.cmu.edu

I'm using the cfront compiler for the HP (series 700), and have tried
to use the compiler switches +e[01] that "optimizes a program to use
less space by ensuring that only one virtual table is generated per
class.  The +e1 option causes virtual tables to be external and
defined (initialized), and the +e0 causes vtables to be external and
not defined.  Without either option, vtables are static."

I'm not sure if this is a general cfront "feature" or a special HP
addition. 

The problem is that if you use these switches on a library, and then
subsequently compile code that derives classes from those in the
library, one cannot avoid including those header files from the
library that define the base classes.  So, when you run your new
headers through +e1, you get lots of duplicate symbols at link time for
those classes in the library that you derive from (and you can't just
compile the whole library +e0 because some classes you don't inherit
from are nonetheless needed when you link).

This behavior makes the switch useless!  My app uses 4 libraries (and
InterViews on top of that), and many of the libraries also have
executables associated with them.  Given that the final executable
size is 30Mb without the +e[01] switches, the system is pretty much
unusable either way.

How do cfront users get around this problem?  Just live with it?  (I
have been using g++, but it has a complementary problem for code size
that comes from creating static copies of all the templates!) Is there
something I'm missing?  Is there some kind of strategy that will solve
the problem?

Since cfront has this very nice -g1 flag already in place (create
debugging info only for the file in which the first non-inline
non-pure virtual function is defined), why couldn't they use the same
logic for the +e1 flag and only produce vtables under the same
conditions.  This would be much easier for the user and would get
around the above problem since it would only define the classes you
are defining functions for, not all classes that appear in the
compiling session!

				- Randy