Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!brutus.cs.uiuc.edu!jarthur!uci-ics!rfg
From: rfg@ics.uci.edu (Ronald Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Request for C++ coding "guidelines"
Keywords: C++, inlines
Message-ID: <25D3D824.15436@paris.ics.uci.edu>
Date: 10 Feb 90 09:00:20 GMT
References: <2754@arran.tcom.stc.co.uk> <25D0B18E.27508@paris.ics.uci.edu> <4446@pegasus.ATT.COM>
Reply-To: rfg@ics.uci.edu (Ronald Guilmette)
Organization: UC Irvine Department of ICS
Lines: 49

In article <4446@pegasus.ATT.COM> hansen@pegasus.ATT.COM (Tony L. Hansen) writes:
>I think that the comments lately have been pointing out problems with some
>current implementations of inline functions:
>
>	When the inline must be outlined, a static version will be created
>	as needed in EVERY .o file where it is needed. When the .o's are
>	combined, you suddenly have N occurrences of the static function
>	which wastes considerable space.
>
>Now, there is nothing in this description of the problem which indicates a
>problem with the language feature. Instead, the real problem is that there's
>currently no implementation which causes those outlined static functions to
>be combined into a single function at link time.
>
>Here's a conceivable implementation for cfront+COFF/ELF-based systems:

[...nice but unusable scheme for combining multiple static out-of-line
    functions into single copies deleted...]

Tony,

I believe that there are two serious problems with your scheme.  First,
some programmers out there have yet to "get religion" when it comes to
avoiding the use of the preprocessor to do evil things.  Thus, you might
see the following code in a C++ header file someday:

	INLINE void foobar ()
	{
		some_var = SOME_MACRO;
	}

Now if you assume that INLINE gets defined to `static' and if you allow
that this header file might get included by two or more "base" files,
you should see that it is at least possible that during these two
independent inclusions, the value of SOME_MACRO may take on two different
values.  If that were the case, then your suggested link-time optimization
(to only pull in one of the two versions of `foobar') would be an "unsafe"
optimization, because it would change the semantics of the resulting
program.

Another problem is that when the compiler decides to out-of-line a
function that was declared as inline, the compiler drops the `inline'
attribute of the function but leave it as `static'.  Thus, your idea
about the linker only pulling in the first available version to satisfy
some outstanding `reference' does not make sense, because unsatisfied
references are (by definition) for "externals" (i.e. extern) and never
for `static' things.

// rfg