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>.
signature.asc
Description: This is a digitally signed message part
