In article <3e784485@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>>>   (Note that it's not obsolete completely; it has one important role which
>>> is a bit different than this. I can explain if someone really wants... :) )
>
>> I think most people here know... ;-)
>
>   Really? Perhaps you are thinking of something else than me.

No, I didn't, but I tried to avoid having to read a page-long message ;-)

>   As long as the compiler is able to inline that function there's no
> problem. However, if for some reason the compiler is unable to inline
> that function, it will create an actual instance of it in the object file,
> which means that you will have the same function implementation in
> several object files.

In fact this depends on the object file format being used.  The standard
does not require not to put code for an inline function into an object file,
and in fact for certain global code optimisation strategies it can be
beneficial to have all functions' code available (also optimisations that
aggressive are rarely used or even implemented).

>   This means that each object file using this function (still supposing
> that the compiler can't inline it) will have a unique ID for this function.
> The function calls of an object file will be directed to the unique instance
> of the function in that object file.

Actually the mangled name (what you call id) will be exactly the same for
all of them, but the linker will recognize the static as part of the mangled
name and for this reason not complain or compilers may decide not not make
static names visible in the object file at all (more common).  This behavior
is required because it is not possible to guarantee a unique name be given
unless the compilers would know about all other instances of the function
(which would require communication).

>   When/if the coder doing this discovers the reason he will probably move
> the function from the header file to a single cpp file to avoid the problem,
> losing the advantage of possibly having it inlined by the compiler.
<snip>
>   This is because the standard requires that if the same 'inline' function
> implementation appears in several object files, the compiler must instruct
> the linker to merge them into one when linking the final binary. This way
> there will be only one instance of the function in the final binary and
> all function calls will call this single instance.

This is not the whole story.  It is very legal to specify inline functions
with external linkage (7.1.2 paragraph 4 of the standard).  This implies
that a linker (!!!) may inline function code.  And in fact some do...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message