Re: Environment to build a squid helper

From: Robert Collins <robertc_at_robertcollins.net>
Date: Wed, 13 Aug 2008 14:13:42 +1000

On Wed, 2008-08-13 at 00:02 -0400, Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Henrik Nordstrom wrote:
> > On tis, 2008-08-12 at 22:52 -0400, Tres Seaver wrote:
> >
> >> Isn't 'extern inline' a contradiction? There should be *no* linkage of
> >> any function being inlined.
> >
> > It depends on your viewpoint.
> >
> > inline is only a hint that the function is a candidate for being
> > inlined. It may still be compiled as a separate function.
>
> But such a function should be *static*, not *extern*: if it is a
> reasonable candidate for inlining, then the cost of linking likely
> dominates the space saved by declariing it 'intern'.
>
> > In GCC "extern inline" then meant that the function should have extern
> > linkage if not inlined, or to be exact a call to an external function if
> > outside of this compile unit if not inlined.
> >
> > Quite useful to avoid repeated duplication of the same function in each
> > comple unit
>
> Inlining involves repeated duplication of the same function (body) at
> each call site, no? If inlining is a good idea (trading space at the
> call site to avoid the overhead of a call setup), then declaring the
> function extern seems silly.

Say I have a function foo. Its inline (which is a hint).

I use it in two translation units (1.cxx and 2.cxx), and call it twice
in both. Say that once it inlines, and once it doesn't.

Then:
 1.o contains foo_MANGLED
 2.o contains foo_MANGLED

By having linkage extern, I can build foo_MANGLED once and link to it
when its not inlined.

If foo_MANGLED is intern, then I end up with two copies of foo_MANGLED
*that were not inlined*. So this is wasted space.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Received on Wed Aug 13 2008 - 04:13:19 MDT

This archive was generated by hypermail 2.2.0 : Wed Aug 13 2008 - 12:00:05 MDT