Re: why not inline all functions

David Chase <>
19 Jun 1998 14:19:00 -0400

          From comp.compilers

Related articles
why not inline all functions? (Mark Sanvitale) (1998-06-09)
Re: why not inline all functions? (1998-06-11)
RE: why not inline all functions (Quinn Tyler Jackson) (1998-06-19)
Re: why not inline all functions (David Chase) (1998-06-19)
Re: why not inline all functions (Dann Corbit) (1998-06-19)
| List of all articles for this month |

From: David Chase <>
Newsgroups: comp.compilers
Date: 19 Jun 1998 14:19:00 -0400
Organization: NaturalBridge LLC
References: 98-06-032 98-06-063 98-06-110
Keywords: linker

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
include file.

David Chase
NaturalBridge LLC

Post a followup to this message

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