[comp.lang.c++] class member declarations

vaughan@puma.cad.mcc.com (Paul Vaughan) (05/26/90)

A long time back I proposed that declaration capability like the
following example be supported:

class Foo;
void Foo::bar(int);

void baz(Foo* f) { f->bar(3); }

where to link a program with this fragment, there must exist a class
declaration

class Foo . . . {
public:
  . . .
  void bar(int);
. . .
};

I believe that it could be easily implemented without imposing
constraints on the linker, simply by generating and using symbols for
the offsets required for generating code with appropriately munged
unique and constructable names.  However, this does not exist in C++.

Now I have an application that routinely does interactive compilation,
but which suffers performance difficulties because of the amount of
material that must be included whenever I use a class.  In particular,
I must include the class definitions for not only Foo, but everything
in Foo's inheritance graph, and everything in the inheritance graphs
of every class of which Foo objects have a member, and so on.  Since
all the information about a class and transitively related classes,
except for the actual code in the function members, must be included
for any code module that uses a member of a class, I claim that C++ is
EXTRAORDINARILY NON-MODULAR.

It's no wonder why people talk about the preprocessed version of a
source module being 50 times longer than the code file.  Fifty times
is conservative--it could be proportional to the size of an entire
application compared to the size of an individual code module.
There's no way to avoid it.

For my application, I'm considering a royal kludge of declaring a lot
of non-class-member functions with self munged names to get around
this problem.  Can you say "DEATH OF OBJECT ORIENTATION?"




 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan

cline@cheetah.ece.clarkson.edu (Marshall Cline) (05/31/90)

In article <8546@cadillac.CAD.MCC.COM> vaughan@puma.cad.mcc.com (Paul Vaughan) writes:

> I must include the class definitions for not only Foo, but everything
> in Foo's inheritance graph, and everything in the inheritance graphs
> of every class of which Foo objects have a member, and so on.  Since
> all the information about a class and transitively related classes,
> except for the actual code in the function members, must be included
> for any code module that uses a member of a class, I claim that C++ is
> EXTRAORDINARILY NON-MODULAR.
>
> It's no wonder why people talk about the preprocessed version of a
> source module being 50 times longer than the code file.  Fifty times
> is conservative--it could be proportional to the size of an entire
> application compared to the size of an individual code module.
> There's no way to avoid it.

The problem Paul describes is severe.  But it is an implementation issue,
not a language issue.  C++ adopted the separate compilation model from C.
This model worked fine for K&R C where you rarely needed include files, but
it's a pain for ANSI C and it's a killer for large C++ projects.  There are
other issues as well as compilation time, such as code bloat from every
module getting static vtables and a static copy of `outlined' inline
functions.  Some of these can be patched, others will require reworking the
underlying compilation model.  However none of these things bother us until
we compile programs that are millions of lines long, which most of us
rarely do :-).

> For my application, I'm considering a royal kludge of declaring a lot
> of non-class-member functions with self munged names to get around
> this problem.  Can you say "DEATH OF OBJECT ORIENTATION?"

I would strongly suggest that you don't generate bad source code just
because today's compiler isn't up to snuff.  Particularly since your
biggest concern is simply waiting for the things to compile.  I suspect
that `real' solutions to the above problems will arrive.  When?  Probably
before most users realize there is a problem!

Marshall Cline
--
==============================================================================
Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676
cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w
Voice: 315-268-3868 / FAX: 315-268-7600
Career search in progress; ECE faculty; research oriented; will send vita.
==============================================================================