在c++中使用内联函数的优点/缺点是什么?我看到它只提高了编译器输出的代码的性能,但随着今天优化的编译器,快速的cpu,巨大的内存等(不像在1980年<内存是稀缺的,所有东西都必须适合100KB内存),他们今天真正有什么优势?
当前回答
在优化过程中,许多编译器会内联函数,即使你没有标记它们。如果你知道一些编译器不知道的东西,你通常只需要将函数标记为内联,因为它自己通常可以做出正确的决定。
其他回答
内联是对编译器的一个建议,它可以随意忽略。它非常适合小段代码。
如果你的函数是内联的,它基本上是插入到函数调用的代码中,而不是实际调用一个单独的函数。这有助于提高速度,因为你不必实际打电话。
它还帮助cpu进行流水线操作,因为它们不必用调用引起的新指令重新加载流水线。
唯一的缺点是可能会增加二进制大小,但只要函数很小,这就不会太大。
现在我倾向于把这类决定留给编译器(好吧,至少是聪明的编译器)。编写它们的人往往对底层架构有更详细的了解。
内联函数更快,因为你不需要将参数和返回地址等东西推入或弹出堆栈;但是,它确实会使二进制文件略大一些。
有显著的区别吗?对大多数人来说,在现代硬件上还不够明显。但它可以产生影响,这对一些人来说已经足够了。
将某些东西标记为内联并不能保证它将是内联的。这只是给编译器的一个建议。有时候是不可能的比如你有一个虚函数,或者涉及到递归。有时候编译器会选择不使用它。
我可以看到这样的情况会产生明显的不同:
inline int aplusb_pow2(int a, int b) {
return (a + b)*(a + b) ;
}
for(int a = 0; a < 900000; ++a)
for(int b = 0; b < 900000; ++b)
aplusb_pow2(a, b);
Generally speaking, these days with any modern compiler worrying about inlining anything is pretty much a waste of time. The compiler should actually optimize all of these considerations for you through its own analysis of the code and your specification of the optimization flags passed to the compiler. If you care about speed, tell the compiler to optimize for speed. If you care about space, tell the compiler to optimize for space. As another answer alluded to, a decent compiler will even inline automatically if it really makes sense.
另外,正如其他人所说,使用内联并不能保证任何东西都是内联的。如果你想要保证它,你必须定义一个宏而不是一个内联函数来实现它。
何时内联和/或定义宏强制包含?-只有当你对关键代码段的速度有了证明和必要的提高,并且知道这对应用程序的整体性能有影响时。
在古老的C和c++中,内联就像寄存器:给编译器一个关于可能的优化的建议(只不过是一个建议)。
在现代c++中,内联告诉链接器,如果在不同的翻译单元中发现了多个定义(不是声明),那么它们都是相同的,链接器可以自由地保留其中一个,并丢弃所有其他的定义。
如果一个函数(无论多么复杂或“线性”)定义在头文件中,内联是强制的,以允许多个源包含它而不会被链接器产生“多个定义”错误。
默认情况下,类内部定义的成员函数是“内联”的,模板函数也是如此(与全局函数相反)。
//fileA.h
inline void afunc()
{ std::cout << "this is afunc" << std::endl; }
//file1.cpp
#include "fileA.h"
void acall()
{ afunc(); }
//main.cpp
#include "fileA.h"
void acall();
int main()
{
afunc();
acall();
}
//output
this is afunc
this is afunc
注意fileA.h包含在两个.cpp文件中,导致两个afunc()实例。 链接器将丢弃其中一个。 如果没有指定inline,链接器将报错。
另一个讨论的结论是:
内联函数有什么缺点吗?
显然,使用内联函数并没有什么错。
但值得注意的是以下几点!
Overuse of inlining can actually make programs slower. Depending on a function's size, inlining it can cause the code size to increase or decrease. Inlining a very small accessor function will usually decrease code size while inlining a very large function can dramatically increase code size. On modern processors smaller code usually runs faster due to better use of the instruction cache. - Google Guidelines The speed benefits of inline functions tend to diminish as the function grows in size. At some point the overhead of the function call becomes small compared to the execution of the function body, and the benefit is lost - Source There are few situations where an inline function may not work: For a function returning values; if a return statement exists. For a function not returning any values; if a loop, switch or goto statement exists. If a function is recursive. -Source The __inline keyword causes a function to be inlined only if you specify the optimize option. If optimize is specified, whether or not __inline is honored depends on the setting of the inline optimizer option. By default, the inline option is in effect whenever the optimizer is run. If you specify optimize , you must also specify the noinline option if you want the __inline keyword to be ignored. -Source