This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ 'extern inline' magic possible?


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.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]