I want to force a little function not to be compiled as inline function even if it's very simple. I think this is useful for debug purpose. Is there any keyword to do this?
The previous two answers are incorrect - many compilers can perform cross-translation-unit inlining. Visual Studio has had it for five years and I believe that GCC can now do it- especially since the OP tagged as Visual C++, it's a fair bet that his compiler can cope.
The simplest way to do this is to take the function's address, and then do something non-meaningless with it, like call it or pass it to an OS/external library function. The compiler can't inline that kind of function.
Why you would ever want to, IDK.
@comments:
If the OP srsly, srsly needs this, then he could compile it as a lib and statically link to it.
Is it possible to force a function not to be inlined?
I won't even attempt to answer that question, because it's irrelevant to be concerned with this except for the two reasons outlined below.
Inlining basically is
- an optimization that's mostly transparent to you
- a way to allow functions to be defined in headers without getting multpile definition errors
(Some would switch the order of these two, but I stick to the traditional order.)
Unless either A) you absolutely need to define a function in some header or B) you are profiling and optimizing a piece of code and know better than the compiler what should be inlined and what shouldn't, inlining should be of no concern to you.
It certainly shouldn't be a concern because of debugging. Your debugger should (and in the case of VC also does) take care of that for you.
You can divide the class implementation between a header and cpp file. if you put the function outside of the class definition, your little function wont be inline.
In Visual Studio 2010, __declspec(noinline)
tells the compiler to never inline a particular member function, for instance:
class X {
__declspec(noinline) int member_func() {
return 0;
}
};
edit: Additionally, when compiling with /clr
, functions with security attributes never get inlined (again, this is specific to VS 2010).
I don't think it will prove at all useful at debugging, though.
Please remember that inlining is relevant at the function call site, the same function can be inlined in some situations and not inlined in other.
If your function is visible outside the compilation unit then even if it's inlined in all the current places it's used the body of the function must still be available for anyone who wants to call it later on (by linking with the object file).
In order to have a call site not inlined you can use a pointer to a function.
void (*f_ptr)(int); // pointer to function
volatile bool useMe = true; // disallow optimizations
if (useMe)
f_ptr = myFunc;
else
f_ptr = useOtherFunc;
f_ptr(42); // this will not be inlined
__declspec(noinline)
for VC++. Contrary to the man page, this appears to work for freestanding functions, and I don't think I've ever used it for a member function. You may -- though note that I never have -- want to consider playing with the optimization flags too, so that only inline
functions are considered for inlining, though of course this has a global effect and that may not be what you want.
__attribute__((noinline))
for gcc (and a number of less-common compilers that support the gcc attribute syntax). I must admit, I don't think I've ever actually used this, but it appears to be there.
(Of course, these two styles of annotation go in different places, so it's a bit annoying to construct code that's palatable to both.)
I'm not sure how either of these interact with the inline
C++ keyword; I've only used them when debugging (when I just want a particular non-inline function left not inline after optimization) or when examining generated code (and I'm getting confused because random stuff is being inlined).
Simple: Don't let the compiler see the definition of the function. Then it cannot possibly be inlined. Of course, that only works if its your code.
When it comes to debugging 3rd party code... yes, this would be useful, especially if you could zap 3rd party code from afar. Anyone who has debugged code that contains lot of shared_ptr dereferencing knows what I'm talking about.