C++ 是否可以强制不内联函数?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/3329214/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is it possible to force a function not to be inlined?
提问by Thomson
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?
我想强制一个小函数不被编译为内联函数,即使它很简单。我认为这对于调试目的很有用。有没有关键字可以做到这一点?
采纳答案by Michael Foukarakis
In Visual Studio 2010, __declspec(noinline)
tells the compiler to never inline a particular member function, for instance:
在 Visual Studio 2010 中,__declspec(noinline)
告诉编译器永远不要内联特定的成员函数,例如:
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).
编辑:此外,在编译时/clr
,具有安全属性的函数永远不会被内联(同样,这特定于 VS 2010)。
I don't think it will prove at all useful at debugging, though.
不过,我认为它在调试时根本没有用。
回答by Michael Foukarakis
__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.
__declspec(noinline)
对于 VC++。与手册页相反,这似乎适用于独立函数,而且我认为我从未将它用于成员函数。您可能——但请注意,我从来没有——也想考虑使用优化标志,以便只inline
考虑内联函数,尽管这当然具有全局影响并且可能不是您想要的。
__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.
__attribute__((noinline))
对于 gcc(以及一些支持 gcc 属性语法的不太常见的编译器)。我必须承认,我认为我从未真正使用过它,但它似乎就在那里。
(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).
我不确定它们中的任何一个如何与inline
C++ 关键字交互;我只在调试时使用它们(当我只想要一个特定的非内联函数在优化后不内联时)或在检查生成的代码时(我很困惑,因为随机的东西被内联了)。
回答by Motti
Please remember that inlining is relevant at the function callsite, 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 allthe 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
回答by John
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 yourcode.
简单:不要让编译器看到函数的定义。那么它不可能被内联。当然,这仅适用于您的代码。
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.
在调试 3rd 方代码时……是的,这很有用,特别是如果您可以从远处扫 3rd 方代码。任何调试过包含大量 shared_ptr 解引用的代码的人都知道我在说什么。
回答by Puppy
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.
许多编译器可以执行交叉翻译单元内联。Visual Studio 已经拥有它五年了,我相信 GCC 现在可以做到——尤其是因为 OP 标记为 Visual C++,他的编译器可以应付是一个公平的赌注。
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.
为什么你会想要,IDK。
@comments:
@注释:
If the OP srsly, srsly needs this, then he could compile it as a lib and statically link to it.
如果 OP srsly,srsly 需要这个,那么他可以将它编译为 lib 并静态链接到它。
回答by LostMohican
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.
您可以在头文件和 cpp 文件之间划分类实现。如果你把函数放在类定义之外,你的小函数就不会内联。
回答by Jan Boonen
If it is a member function of a class, make it virtual.
如果它是类的成员函数,请将其设为虚拟。
回答by sbi
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 definea 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.
除非A)您绝对需要在某个头文件中定义一个函数或B)您正在分析和优化一段代码并且比编译器更了解什么应该内联,什么不应该,内联应该与您无关.
由于调试,这当然不应该成为问题。您的调试器应该(在 VC 的情况下也是如此)为您处理这些问题。