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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/01/2011 02:55 AM, Jonathan Wakely wrote:
On 1 March 2011 03:53, Ian Lance Taylor wrote:
Jonathan Wakely<jwakely.gcc@xxxxxxxxx>  writes:

On 1 March 2011 00:25, Ian Lance Taylor  wrote:
"Kevin P. Fleming"<kpfleming@xxxxxxxxxx>  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?

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@xxxxxxxxxx
Check us out at www.digium.com & www.asterisk.org


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux