DEV Community

mdh81
mdh81

Posted on • Updated on

Unraveling the inline mess in C++

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:

Image description

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)

Collapse
 
pauljlucas profile image
Paul J. Lucas

In short, I'm not a fan of this C++ feature.

So what would you have the compiler do instead?

Collapse
 
mdh81 profile image
mdh81

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.

Collapse
 
pauljlucas profile image
Paul J. Lucas

1) Not overload inline keyword for ODR purposes

So what exactly would inline (or implicit inline within a class) do, then? And how would you request relaxing ODR if it's not inline?

2)

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 inline is implemented in C instead?

Thread Thread
 
mdh81 profile image
mdh81 • Edited

So what exactly would inline (or implicit inline within a class) do, then? And how would you request relaxing ODR if it's not inline?

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.cpp includes a.h and b.h and they both have a definition for foo(), then there is a true problem. If I have src1.cpp and src2.cpp and they both include a.h, I wish there was an intelligent mechanism to determine that only a single definition of foo exists.

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 inline keyword. I'd have preferred inline do it's original job and have a separate keyword for marking functions that have a single definition.

I'd think the warning should be opt-in rather than opt-out; otherwise it likely would get too noisy.

Agreed.

BTW: do you prefer the way inline is implemented in C instead?

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.