In article <2du8et$lse@net1.ics.uci.edu>,
Douglas C. Schmidt <schmidt@ics.uci.edu> wrote:
>In article <nagleCHLBrM.LJy@netcom.com>, John Nagle <nagle@netcom.com> wrote:
>++      Only because a dumb linker is assumed.  Other languages, such as
>++ Modula and Ada, have "binders" which deal with this issue at link time.
>
> Actually, if you take a look at Ada it uses the private
>section of a package specficiation to place type information in much
>the same way and for much the same reason that C++ defines the
>per-instance data in the private section of a class.

In Ada, you do declare the private data type information, but
not the private subprograms.  The private subprograms are
declared in the package body, to minimize recompilation.

Quite a while ago I asked why C++ requires all private
(static) member functions to be declared in the class declaration,
and the response was that such declarations are part of the
"abstraction."  Furthermore, you can use a friend declaration
to identify a helper class where you can declare the
equivalent of additional static member functions.  It seems
kind of roundabout, but I suppose it works.

> Doug

S. Tucker Taft   stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138

kaufman@eecs.nwu.edu (Michael L. Kaufman) writes:

>In article <2drsl5$dta@access.digex.net>,
>Keith R. Bennett <kbennett@access.digex.net> wrote:
>>This being the case, why are private data and function members
>>included in the class header?

>It is a compiler issue. The compiler needs to know how big the class is.

     Only because a dumb linker is assumed.  Other languages, such as
Modula and Ada, have "binders" which deal with this issue at link time.

     Costs C++ users a huge number of redundant recompiles.

      John Nagle

In article <nagleCHLBrM.LJy@netcom.com>, John Nagle <nagle@netcom.com> wrote:
++      Only because a dumb linker is assumed.  Other languages, such as
++ Modula and Ada, have "binders" which deal with this issue at link time.

 Actually, if you take a look at Ada it uses the private
section of a package specficiation to place type information in much
the same way and for much the same reason that C++ defines the
per-instance data in the private section of a class.

++      Costs C++ users a huge number of redundant recompiles.

 I believe that toolkits (e.g., purify) are emerging that can
reduce this overhead for C++, as well.  Eventually, this issue will
become irrelevant since it's just another example of "accidental
complexity" that arises from limitations with existing tools we often
use for reasons of portability and familiarity, etc.

 Doug

--
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | schmidt@ics.uci.edu
And say to all the world: "This was a man."         | ucivax!schmidt
   -- In loving memory of Terry Williams (1971-1991)| (714) 856-4105

In article <2du8et$lse@net1.ics.uci.edu> schmidt@ics.uci.edu (Douglas
C. Schmidt) writes:
>++      Costs C++ users a huge number of redundant recompiles.

> I believe that toolkits (e.g., purify) are emerging that can
>reduce this overhead for C++, as well.  Eventually, this issue will
>become irrelevant since it's just another example of "accidental
>complexity" that arises from limitations with existing tools we often
>use for reasons of portability and familiarity, etc.

purify helps, but there are some fundamental problems with current C++
implementations.  Name mangling does force recompiles.  It is often
hard to know what to recompile and what not to, so the whole world
often ends up being recompiled just to be safe.  Thinks like changing
a function to be a const function, or parameters to be const, etc
cause this.

However, the biggest cause of recompiles is the addition/deletion of
virtual functions.  Wish someone could come up with a clean way of
dealing with virtual functions that didn't rely on a table where
function offsets in the table can move about.  I know it is a hard
problem, but given the number of cycles that have beeen devoted to
recompiling OI alone, you'd think that someone would have come up
with a useful scheme by now.

Warner
--
Warner Losh  imp@boulder.parcplace.COM ParcPlace Boulder
I've almost finished my brute force solution to subtlety.