Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!cs.utexas.edu!rutgers!cunixf.cc.columbia.edu!cs.columbia.edu!kearns
From: kearns@cs.columbia.edu (Steve Kearns)
Newsgroups: comp.lang.c++
Subject: Re: Borland Turbo C++ compile size
Keywords: topspeed linking
Message-ID: <1990Aug9.173850.3049@cs.columbia.edu>
Date: 9 Aug 90 17:38:50 GMT
References: <7921@tekgvs.LABS.TEK.COM> <380@taumet.com> <1990Aug4.233013.20500@cs.columbia.edu> <2614@dataio.Data-IO.COM>
Reply-To: kearns@cs.columbia.edu (Steve Kearns)
Followup-To: comp.lang.c++
Organization: Columbia University Department of Computer Science
Lines: 26

In article <2614@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
>In article <1990Aug4.233013.20500@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes:
><The "problem" with "hello world" in C++ illustrates the need for
><smart linking, as provided by the Topspeed C compiler:  it only includes,
><in an executable, the functions and variables actually needed for the
><program being linked.  In contrast, all other linkers I know about today
><include every function and variable defined in a file, if just 1 function
><or variable is accessed.  
><......
><How about it, compiler vendors?  Give us smart linking, please!
>
>There is no difference between 'smart linking' and organizing the code
>so that there is one function per OBJ file, and putting the OBJ files
>into a library. Smart linking is simply a more convenient way to do it.
>.....
>I think you'll find this feature of limited value in C++ programs. The
>reason is that virtual functions are *always* referenced (because of
>their entry in the virtual function pointer table). Since most of the
>complexity of classes is typically handled by virtual functions, they
>all tend to get pulled in if any constructors are referenced.

I would call this "dumb smart linking".  Then I propose "smart smart
linking", in which the linker/compiler understands virtual functions
and avoids the problem Walter points out.

-steve