Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uunet!taumet!steve
From: steve@taumet.com (Stephen Clamage)
Newsgroups: comp.lang.c++
Subject: Re: Borland Turbo C++ compile size
Message-ID: <383@taumet.com>
Date: 5 Aug 90 14:53:19 GMT
References: <7921@tekgvs.LABS.TEK.COM> <380@taumet.com>, 	<1990Aug4.233013.20500@cs.columbia.edu> <Uaitime00VB5E1pYAT@andrew.cmu.edu>
Organization: Taumetric Corporation, San Diego
Lines: 46

aw1r+@andrew.cmu.edu (Alfred Benjamin Woodard) writes:

|kearns@cs.columbia.edu (Steve Kearns) writes:
|> The "problem" with "hello world" in C++ illustrates the need for
|> smart linking ...
|> Smart linking relieves the fear
|> that using a large class for a simple purpose imposes a severe penalty on
|> memory usage and program size.  
|
|From everything that I have heard smart linking seems like a really
|good idea. Why doesn't everybody do it? Is it extrodinarily hard to
|write or something? How can it deal with things like virtual functions?

The main problem with smart linking is dealing with the rest of the
world.  If I as a vendor am free to define my own object file format
and write my own linker, it is not so hard to make a smart linker.
But this creates mixed-language and mixed-vendor problems, trying to
deal with different-format object files.  I also have to provide a
linker that can use the local object file format on every system I
support.  And the local linker will always have some unique feature
that users of that system have come to depend on, which I have to 
supply in that version of my linker.  It gets to be a real mess.

Now in the case of virtual functions, the problem is quite a bit
harder.  In the standard implementation, for each class with virtual
functions, there is a table of function addresses.  To resolve a
function address, a function must be included in the executable
file, even if it is never called.  So either the compiler or the
linker must somehow be able to determine whether a given virtual
function is ever called in the entire program before deciding whether
to include the function or its address.  The currently-popular
separate-compilation model does not support this very well.

What we need is to get away from the current model of separate source
text files, separate object files, separate compilation, separate linking.
We need a more integrated environment.  For example, typical real-world
C programs may include thousands of lines of header files for each
module, the header files processed over and over.  This is very wasteful.

The editing/compiling/linking processes could be more integrated, whereby
a database is maintained to keep track of things.  As you edit a
program, it could be incrementally compiled, incrementally linked, as
you go.  This would dramatically improve productivity.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com