|why not inline all functions? firstname.lastname@example.org (Mark Sanvitale) (1998-06-09)|
|Re: why not inline all functions? email@example.com (1998-06-11)|
|RE: why not inline all functions firstname.lastname@example.org (Quinn Tyler Jackson) (1998-06-19)|
|Re: why not inline all functions email@example.com (David Chase) (1998-06-19)|
|Re: why not inline all functions firstname.lastname@example.org (Dann Corbit) (1998-06-19)|
|From:||"Quinn Tyler Jackson" <email@example.com>|
|Date:||19 Jun 1998 10:33:06 -0400|
Further to the question "Why not inline all functions" ...
Doing so would mesh a given implementation of a utility library so
intricately with the compiled system that used that utility library
that a full build would be required every time a function's
implementation changes, in order to guarantee that all instances of
the use of those functions took into account changes.
In linked builds, only those components that actually change need be
rebuilt and recertified. This also allows for the implementation of
binary patches in a finite number of fairly well defined places should
a bug be discovered. Techniques such as function entry point thunks
to work arounds would be useless. (Yes, sure they're ugly, but they
prove economical in the real world.)
In nontrivial systems, the cost of rebuilding an entire set of utility
libraries every time one (very possibly unrelated) function is changed
would be prohibitive.
Since I have always believed that every change in code breaks the code
until proven otherwise, even given an infinitely fast compiler that
never optimized an inline into oblivion, an infinite amount of coffee
would be consumed during the subsequent reprofiling and
recertification of the resulting systems.
Return to the
Search the comp.compilers archives again.