In my previous post about inline keyword, I loudly wondered:
I still don't know if a function that's implicitly inline is actually inlined when it's invoked. There is this c++ maxim that says "inline is only a hint and the compiler is free to ignore it". Does that apply to implicitly inlined functions? In other words, if I were to stick a 500 line definition for a function that's defined in the class definition, will the compiler still inline it?
Turns out, this is a valid question because the compiler is NOT guaranteed to inline a member functions that are present in class definitions even though defining them in the class definition implicitly defines them as inline
The answers in this SO clearly states that it's still up to the compiler's discretion to actually inline the calls to this function. I have highlighted the relevant sections from an upvoted answer:
The last comment is more telling because it exactly talks about what was happening to the non-member friend function defined in Foo.h in the previous post. If you were to create a header only library, if you don't use the inline keyword for your non-member functions, you will end up make your library useless. You won't catch this error unless you include your header in multiple sources in your tests (something that's easy to do).
In short, I'm not a fan of this C++ feature. I see SO responses that go to great lengths to explain the feature, but I don't think even the gurus can point to this feature as a strength of the language.
Top comments (4)
So what would you have the compiler do instead?
1) Not overload inline keyword for ODR purposes
2) Emit a helpful message when an inline request cannot be fulfilled so developers understand compiler’s rationale.
So what exactly would
inline(or implicitinlinewithin a class) do, then? And how would you request relaxing ODR if it's notinline?I'd think the warning should be opt-in rather than opt-out; otherwise it likely would get too noisy.
BTW: do you prefer the way
inlineis implemented in C instead?In an ideal world, I'd expect ODR violations only when there are two or more distinct definitions for a function. In other words, if
src.cppincludesa.handb.hand they both have a definition forfoo(), then there is a true problem. If I havesrc1.cppandsrc2.cppand they both includea.h, I wish there was an intelligent mechanism to determine that only a single definition offooexists.I realize this is easier said than done since the compiler only deals with a single compilation unit at a time. But, strictly speaking, there is no programmer error here, there is only one definition of the function, but because of the way inner machinery of the language works, the linker sees multiple definitions of the same function.
Since the burden is on the programmer to resolve this, I'd have preferred a less confusing resolution than overloading the use of
inlinekeyword. I'd have preferredinlinedo it's original job and have a separate keyword for marking functions that have a single definition.Agreed.
Haven't programmed in C since my college days :) It's not clear to me how this is better than C++. Again, for me, overloading the inline keyword to control enforcement of one-definition rule seems complicated. I'd have preferred a separate keyword.