kearns@cs.columbia.edu (Steve Kearns) (08/05/90)
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. Since C++ encourages the creation of large robust classes, one expects that a class implementation will contain a number of functions that are not actually used in an application. Smart linking relieves the fear that using a large class for a simple purpose imposes a severe penalty on memory usage and program size. How about it, compiler vendors? Give us smart linking, please! -steve
aw1r+@andrew.cmu.edu (Alfred Benjamin Woodard) (08/05/90)
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. > > Since C++ encourages the creation of large robust classes, one expects > that a class implementation will contain a number of functions that > are not actually used in an application. Smart linking relieves the fear > that using a large class for a simple purpose imposes a severe penalty on > memory usage and program size. > > How about it, compiler vendors? Give us smart linking, please! > > -steve I was planning to post this to some question list but since the topic came up here I will ask the question now. 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? -ben
steve@taumet.com (Stephen Clamage) (08/05/90)
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
r91400@memqa.uucp (Michael C. Grant) (08/06/90)
In article <383@taumet.com>, steve@taumet.com (Stephen Clamage) writes: > 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. I personally use Think C, which you could call 'C+' because it is C which has a C++-like class handling set. On the Mac, an 'integrated' programming environment is essential, and Think C provides it. It performs incremental compilation, and linking is amazingly fast--and, it provides SMART LINKING! It would be awfully nice if Symantec would come out with an actual C++ compiler using the same user interface--I KNOW it would sell. But, for now, I can't use references, or overload operators, or hide my private variables from view, but I can use classes and that is a step in the right direction. And, since I work for Motorola, I won't be using ANYTHING but Macintoshes anyway. :-) Michael C. Grant
bright@Data-IO.COM (Walter Bright) (08/07/90)
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.
<Since C++ encourages the creation of large robust classes, one expects
<that a class implementation will contain a number of functions that
<are not actually used in an application. Smart linking relieves the fear
<that using a large class for a simple purpose imposes a severe penalty on
<memory usage and program size.
<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.
A standard linker could be used if the compiler emitted .LIB files
instead of .OBJ files (thus extending the OBJ file format is not
necessary).
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.kearns@cs.columbia.edu (Steve Kearns) (08/10/90)
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
tma@osc.COM (Tim Atkins) (08/12/90)
Be very careful with recommendations on "smart" linking. Some implementations I am aware of can break the munch form of C++ loading. The reason is that the executable is first linked, then an nm is done to find the special static constructors and destructors. This input is used to produce another .c file that calls these functions. Some "smart" linkers make this impossible as the relevant static functions are discarded in phase one since there are no calls to them at that point. While I consider the goal of smart linking laudable, some support for programs that depend on current practice or a modification of current practice is needed.