C++ 'extern inline' magic possible?

[David Brown]

On 01/03/2011 13:14, Kevin P. Fleming wrote:
> On 03/01/2011 02:55 AM, Jonathan Wakely wrote:
>> On 1 March 2011 03:53, Ian Lance Taylor wrote:
>>> Jonathan Wakely<jwakely.gcc@gmail.com> writes:
>>>
>>>> On 1 March 2011 00:25, Ian Lance Taylor wrote:
>>>>> "Kevin P. Fleming"<kpfleming@digium.com> writes:
>>>>>
>>>>>> I would like to come up with some construction like the 'extern
>>>>>> inline' that GCC supports for C mode, so that a.h could contain the
>>>>>> declaration *and* definition of 'bar', allowing code that includes
>>>>>> a.h
>>>>>> to have 'bar' be inlined if the compiler chooses to do so (and leave
>>>>>> an external reference to 'bar' if necessary so that the version built
>>>>>> from a.cpp will be used). So far my attempts have only resulted in
>>>>>> various re-definition or re-declaration errors.
>>>>>
>>>>> There is no equivalent to GNU C's "extern inline" in C++. By the way,
>>>>> "extern inline" is now actually known as __attribute__ ((gnu_inline)),
>>>>> as C99 defines "extern inline" to mean something different.
>>>>>
>>>>> In C++ you can simply define the function inline in a.h, and not
>>>>> define
>>>>> it at all in a.cpp. The right thing will happen.
>>>>
>>>> That will work in practice, but it's technically an ODR violation.
>>>
>>> No, it's not (there may be a misunderstanding somewhere). I am
>>> suggesting that there should be only one definition: the one in a.h.
>>> That is OK if the definition has inline linkage. It is certainly not an
>>> ODR violation, as there is only one definition.
>>
>> Yes sorry, I did misunderstand. But in that case a.h must be included
>> by all callers of the function. I thought the point was some callers
>> don't want to include the definition of the class and the function
>> that uses it.
>
> Yes, that was what my original post requested, but I now understand that
> any solution that offered that would be non-compliant with the C++
> standard. I believe this code base is only using this technique to shave
> some compile time for TUs that don't actually need the class definitions
> (they only receive and send around pointers to the classes), but it's a
> cause of lower performance and so I'll have to figure out whether
> removing the 'forward declaration only' mechanism will be worth the effort.
>
> Thanks for the replies; as usual the level of knowledge and helpfulness
> on this mailing list is stellar :-)
>
> On a slightly related note... I've seen a couple of pages (but not the
> GCC manual's 'inlining' page) mention that it's possible for virtual
> member functions to be inlined if they are inlinable (either defined in
> the class declaration or the function declaration is visible and marked
> 'inline') and the call to them is a 'direct virtual function call'. This
> last term doesn't make any sense to me, and based on my understanding of
> vtables I don't see how a virtual member function could *ever* be
> inlined unless it was called in a non-virtual fashion (i.e. calling it
> as "Foo::bar()" when Foo is the class making the call or one of its
> bases). In any other situation, the compiler cannot know at compile time
> which member function would actually be called. Does this sound like a
> correct statement?
>

The compiler is free to inline functions as part of its optimisations. 
To do that, it needs to be sure what functions to call, and to have 
access to the definition of the function.  Marking a function "inline" 
is a hint that you'd like inlining, but the compiler may not be able to 
inline a function marked "inline", and it may also choose to inline 
functions that are not marked.

This will apply equally to virtual methods.  If the compiler can be sure 
of which function is actually being called with the virtual method call, 
it can remove the indirection and call the underlying function directly, 
or inline it.

If you want the compiler to inline functions where practical, even 
across different compilation units, and to use function calls when 
necessary, then you should look hard at using LTO.  This gives the 
compiler the chance to inline function calls even though the definitions 
are not available in the compilation unit in which they are used.