Understanging the use of inline funtions

[John Fine]

Ian Lance Taylor wrote:
>
> Such as __attribute__ ((noinline)).  The Intel compiler recognizes a lot
> of gcc attributes and may recognize that one.
>
>
>   
Yes Intel 10 recognizes that.  No it doesn't act reasonably in response 
to it.

As implied by some of the linkage info you just described, the inline 
rules of the language interact with the ODR.  In a big project, that is 
often the problem.

Anything that must be defined in a header file (and included by more 
than one compilation whose objects will then be linked) needs to be 
covered by some exception in the One Definition Rule.

The Intel 10 compiler strictly ties together all exceptions in the ODR 
with the hint to inline.

So when you make it understand __attribute__ ((noinline)) as turning off 
the hint to inline a particular function, that necessarily also turns 
off the exception in ODR.  So if the header is included in more than one 
.cpp, you will get a link time multiple definition error.

Intel 10 does generate the form of a function that is not inline but 
also not subject to link time multiple definition errors.  But it only 
does so when its own heuristics make it override what it considers an 
implicit request to inline a function, and that never happens on any of 
the functions where competent design would select not inlining.  It 
cannot be told to apply this behavior to a specific function.

To the best of my understanding, GCC gets this right.  If you start with 
a definition in a header file that is (for any reason) an exception in 
the ODR together with a hint to inline, and then you add __attribute__ 
((noinline)) you get that behavior I can't get from Intel 10:  A 
definition that is still an exception to ODR, but is no longer inlined.