内联允许您在头文件中放置函数定义，并在多个源文件中#包含该头文件，而不违反一个定义规则。

另一个讨论的结论是:

内联函数有什么缺点吗?

显然，使用内联函数并没有什么错。

但值得注意的是以下几点!

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

优势

通过在需要的地方内联代码，程序将在函数调用和返回部分花费更少的时间。它应该使您的代码运行得更快，即使它变得更大(见下文)。内联普通访问器可以是有效内联的一个例子。 通过将其标记为内联，你可以将函数定义放在头文件中(即它可以包含在多个编译单元中，而链接器不会抱怨)

缺点

It can make your code larger (i.e. if you use inline for non-trivial functions). As such, it could provoke paging and defeat optimizations from the compiler. It slightly breaks your encapsulation because it exposes the internal of your object processing (but then, every "private" member would, too). This means you must not use inlining in a PImpl pattern. It slightly breaks your encapsulation 2: C++ inlining is resolved at compile time. Which means that should you change the code of the inlined function, you would need to recompile all the code using it to be sure it will be updated (for the same reason, I avoid default values for function parameters) When used in a header, it makes your header file larger, and thus, will dilute interesting informations (like the list of a class methods) with code the user don't care about (this is the reason that I declare inlined functions inside a class, but will define it in an header after the class body, and never inside the class body).

内联魔法

The compiler may or may not inline the functions you marked as inline; it may also decide to inline functions not marked as inline at compilation or linking time. Inline works like a copy/paste controlled by the compiler, which is quite different from a pre-processor macro: The macro will be forcibly inlined, will pollute all the namespaces and code, won't be easily debuggable, and will be done even if the compiler would have ruled it as inefficient. Every method of a class defined inside the body of the class itself is considered as "inlined" (even if the compiler can still decide to not inline it Virtual methods are not supposed to be inlinable. Still, sometimes, when the compiler can know for sure the type of the object (i.e. the object was declared and constructed inside the same function body), even a virtual function will be inlined because the compiler knows exactly the type of the object. Template methods/functions are not always inlined (their presence in an header will not make them automatically inline). The next step after "inline" is template metaprograming . I.e. By "inlining" your code at compile time, sometimes, the compiler can deduce the final result of a function... So a complex algorithm can sometimes be reduced to a kind of return 42 ; statement. This is for me extreme inlining. It happens rarely in real life, it makes compilation time longer, will not bloat your code, and will make your code faster. But like the grail, don't try to apply it everywhere because most processing cannot be resolved this way... Still, this is cool anyway...:-p

这并不完全是关于性能。c++和C都用于嵌入式编程，位于硬件之上。例如，如果您要编写中断处理程序，则需要确保代码可以立即执行，而不会交换额外的寄存器和/或内存页。这就是内联派上用场的时候。好的编译器在需要速度时自己做一些“内联”，但“内联”迫使它们这样做。

我想补充一点，在构建共享库时，内联函数是至关重要的。如果不将函数标记为内联，则它将以二进制形式导出到库中。如果导出，它也将出现在符号表中。另一方面，内联函数不会被导出，既不会被导出到库二进制文件中，也不会被导出到符号表中。

当库打算在运行时加载时，它可能是关键的。它还可能打击二进制兼容的库。在这种情况下，不要使用内联。

在将函数内联到so库时遇到了同样的麻烦。似乎内联函数没有编译到库中。因此，如果一个可执行文件想要使用库的内联函数，链接器会输出一个“未定义引用”错误。(我碰巧用gcc 4.5编译Qt源代码。