unintended inlining

[Peter87]

So I just played around with Compiler Explorer and I noticed that compilers still pay a lot of attention to the inline keyword. Clang treats functions that are implicitly inline, because they are defined inside the class definition, differently compared to if the inline keyword is explicitly used. GCC doesn't seems to make this distinction.

My concern is that we accidentally write functions thinking we leave the decision entirely up to the compiler when in fact the compiler think that we strongly want the functions to be inlined.

For regular classes I seldom define functions inside class definition. Not even for small functions that I think should be inlined. Instead I rely on link-time optimizations and the compiler's ability to make good decisions. I hope this works but I haven't made any investigations.

For class templates I have sometimes defined functions inline because I can't move the definitions to another source file anyway and moving them outside adds a lot of boilerplate. I now think this might have been a bad idea. Moving the definitions outside the class template definition is probably the right thing to do.

I'm not sure if anyone has any thoughts on this, otherwise I guess my advice is to be careful with what functions that you make inline, and watch out for implicit inline.

[kbw]

I'm kinda do the opposite. In my experience, compilers are rarely as clever as I want them to be.

So I tend error on the side of making things inlined, then let the compiler refuse to inline the, rather than expecting the compiler to choose.

I also think it gives the optimizer more information.

[jonnin]

there are nonstandard directives:

__declspec(noinline) for VC++.

__attribute__((noinline)) for gcc (??) //I think?

[Peter87]

Well, what I mainly want from the compiler is to inline functions that are only used once or are small enough that it doesn't increase the size of the program too much. This is pretty much what GCC's -O2 does. In performance critical code I would certainly use inline if I know that is what I want.

It is unfortunate that the inline keyword in C++ means two things.
1. Multiple definitions allowed, must be defined in all translation units where it's used.
2. Hint to the compiler that the function should be inlined.
This makes it impossible to split the declaration and definition into header and source files which is one of the reasons why I tend to never use inline for member functions. Now that we have got link-time optimizations there is no reason why these two concepts should be bundled together.

[jonnin]

visual supports a force-inline directive and it will ensure inline on anything that CAN be inline (a few things simply cannot be inline).

If you don't have that, you can take the body of the function and put it in a text file (I don't like .cpp or .h for this ... but the extension is unimportant) and # include it where you want it. This will inline the code. You can also use a macro for very small, simple items, but I recommend against that generally.

I don't know if g++ has a force or not. Google around to see. Most of the things one would want to do have been thought of already and features added to support them...

[Peter87]

Yeah, I think all compilers have ways of disabling and forcing inlining of functions. It shouldn't be that hard to put together a macro to handle it in a cross-platform manner.