Re: How do linkers deal with C++ duplicate code?

John R Levine <johnl@iecc.com> writes:


> How do linkers deal with C++ duplicate code?


The short answer: not very well...


>-- Templates and extern inline. This I understand the least. The
>problem is that with separate compilation, multiple modules can
>contain identical (or at least equivalent) copies of expanded
>templated routines and extern inlines. One approach is to pretend
>they're all static and live with the code bloat, although as recently
>noted, the bloat can be pretty horrible. But some systems actually
>identify and discard the duplicates. What do they do, treat them as
>name-mangled common blocks full of code and discard all but one of
>them? Something cleverer?


Most aren't even as clever as that. For extern inlines, many
compilers output bodies (and vtables) only when they see the body of
the first virtual function in the class. Hopefully that function is
defined in the .cpp file and thus isn't duplicated. (But many C++
compilers happily duplicate vtables and inlines if the first virtual
happens to be inline, i.e., has a body in the .h file.)


The standard strategy for templates is to keep a "template database"
that contains the object files of template instantiations. The linker
links the program with the files of this DB, and if it encounters
unresolved template references it invokes the compiler to instantiate
the missing template(s) and add them to the DB. However, this scheme
itself doesn't protect against duplication that occurs when several
template instantiations expand to the same code (e.g., List<T>).


With the limitations of most current C++ compilers, it is fairly easy
to (accidentally or intentionally) write code that produces extremely
bloated executables (another standard problem are duplicated debugging
symbols). A few compilers (e.g., IBM's VisualAge 4.0, not available)
seem to do better, but I don't know in detail how they do it. But
they all abandon the "use the C linker plus a bunch of hacks"
approach; VA 4.0 even abandons the traditional source file approach in
favor of a program database.


-Urs
--

Return to the comp.compilers page.
Search the comp.compilers archives again.