|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:||David Chase <email@example.com>|
|Date:||19 Jun 1998 14:19:00 -0400|
|References:||98-06-032 98-06-063 98-06-110|
Quinn Tyler Jackson wrote:
> 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.
This is not strictly true. I have seen an existence proof (my
colleagues have written) a system that tracks all the dependences
of an application on the libraries linked into it, at a rather fine-
grained basis. This was also a property of Modula-3 systems, at
some level of granularity. If you poke some bottom-most library
function, then yes, go out for a very long lunch, but typically
the functions that get changed do not provoke total recompilation.
Yes, it does complicate patches, and woe to you if you build
with inlining set to 11, tweak one file, and think a simple
relink (as opposed to one requesting that dependences be
respected) will propagate the change. This is not very
different from circumventing "make" after a change to an
Return to the
Search the comp.compilers archives again.