1)如今，几乎从来没有。如果内联一个函数是个好主意，编译器会在没有你帮助的情况下完成它。

2)。看到# 1。

(经过编辑，反映出你把问题分成了两个问题……)

c++内联与C内联完全不同。

#include <iostream>
extern inline int i[];
int i [5];
struct c {
  int function (){return 1;} // implicitly inline
  static inline int j = 3; // explicitly inline
  static int k; // without inline, a static member has to be defined out of line
  static int f (){return 1;} // but a static method does not // implicitly inline
};

extern inline int b;
int b=3;
int c::k = 3; // when a static member is defined out of line it cannot have a static
              // specifier and if it doesn't have an `inline` specifier in the
              // declaration or on the definition then it is not inline and always
              // emits a strong global symbol in the translation unit

int main() {
  c j;
  std::cout << i;
}

inline on its own affects the compiler, assembler and the linker. It is a directive to the compiler saying only emit a symbol for this function/data if it's used in the translation unit, and if it is, then like class methods, tell the assembler to store them in the section .section .text.c::function(),"axG",@progbits,c::function(),comdat or .section .bss.i,"awG",@nobits,i,comdat for unitialised data or .section .data.b,"awG",@progbits,b,comdat for initialised data. Template instantiations also go in their own comdat groups.

This follows .section name, "flags"MG, @type, entsize, GroupName[, linkage]. For instance, the section name is .text.c::function(). axG means the section is allocatable, executable and in a group i.e. a group name will be specified (and there is no M flag so no entsize will be specified); @progbits means the section contains data and isn't blank; c::function() is the group name and the group has comdat linkage meaning that in all object files, all sections encountered with this group name tagged with comdat will be removed from the final executable except for 1 i.e. the compiler makes sure that there is only one definition in the translation unit and then tells the assembler to put it in its own group in the object file (1 section in 1 group) and then the linker will make sure that if any object files have a group with the same name, then only include one in the final .exe. The difference between inline and not using inline is now visible to the assembler and as a result the linker, because it's not stored in the regular .data or .text etc by the assembler due to their directives. Only inline symbols with external linkage are given external comdat linkage like this -- static linkage (local) symbols do not need to go in comdat groups.

inline on a non-static method declaration in a class makes the method inline if it is defined out-of-line, this will prevent the method being emitted in the translation unit if it is not referenced in the translation unit. The same effect is achieved by putting inline on the out-of-line definition. When a method is defined out-of-line without an inline specifier and the declaration in the class is not inline then it will emit a symbol for the method in the translation unit at all times because it will have external linkage rather than external comdat linkage. If the method is defined in the class then it is implicitly inline, which gives it external comdat linkage rather than external linkage.

static inline on a member in a class (as opposed to method) makes it a static member (which does not refer to its linkage -- it has the linkage of its class which may be extern). static inline also allows static members of the class to be defined inside the class instead of needing to be declared in the class and then defined out-of-line (without static in the definition, which wasn't allowed without -fpermissive). *static inline* also makes the members inline and not static inline -- inline means that the definition is only emitted if it is referenced in the translation unit. Previously you had to specify inline on the out-of-line definition to make the member inline.

由于静态方法可以在类中定义，因此静态内联对类中定义的静态方法没有影响，类中定义的静态方法始终具有外部链接，是静态方法并且是内联的。如果它被定义在行外，那么inline必须被用来使它成为内联(即给予外部comdat链接而不仅仅是外部链接)，static仍然不能被使用。

static inline at file scope only affects the compiler. It means to the compiler: only emit a symbol for this function/data if it's used in the translation unit and do so as a regular static symbol (store in.text /.data without .globl directive). To the assembler there is now no difference between static and static inline. Like the other forms of inline, it cannot be used on a class, which is a type, but can be used on an object of the type of that class. This form of static inline also cannot be used on members or methods of a function, where it will always be treated inline as the static means something else in a class (it means that the class is acting as a scope rather than it being a member of or method to be used on an object).

Extern inline是一个声明，意味着如果它被引用或抛出编译器错误，则必须在翻译单元中定义此符号;如果定义了它，那么将它视为常规的内联，对于汇编器和链接器，extern内联和内联之间没有区别，因此这只是一个编译器保护。

extern inline int i[];
extern int i[]; //allowed repetition of declaration with incomplete type, inherits inline property
extern int i[5]; //declaration now has complete type
extern int i[5]; //allowed redeclaration if it is the same complete type or has not yet been completed
extern int i[6]; //error, redeclaration with different complete type
int i[5]; //definition, must have complete type and same complete type as the declaration if there is a declaration with a complete type

如果没有错误行，上面的全部内容将折叠为inline int i[5]。显然，如果你做了extern inline int i[] = {5};然后，由于通过赋值显式定义，extern将被忽略。

I think the reason that static is not allowed on a static out-of-line definition without -fpermissive is because it implies that the static refers to static linkage, because it's not immediately obvious to the programmer that it is a member of a class or whether that class has , where the static means something different. -fpermissive ignores the static specifier on the out-of-line definition and it means nothing. In the case of a simple integer, k can't be defined out of a namespace, if c were a namespace, but if k were a function, then there would be no way of visibly telling from the line of code whether it is an out of line definition of a function in a namespace with static linkage, or an out-of-line definition of a static member with external linkage, and may give the wrong impression to the programmer / reader of the code.

对于局部类，在成员/方法上内联将导致编译器错误，并且成员和方法没有链接。

关于命名空间上的内联，请参见this和this

你要把它放在最开始，在返回类型之前。但是大多数编译器忽略了它。如果它是定义的，并且它的代码块较小，大多数编译器都认为它是内联的。

什么时候编译器不知道什么时候使一个函数/方法'内联'?

这取决于所使用的编译器。不要盲目相信现在的编译器比人类更了解如何内联，也不要因为性能原因而使用它，因为它是链接指令而不是优化提示。虽然我同意这些观点在意识形态上是正确的，但遇到现实可能是另一回事。

在阅读了多个线程之后，出于好奇，我尝试了内联对我正在工作的代码的影响，结果是我得到了GCC的可测量加速，而英特尔编译器的速度没有提高。

(更多细节:数学模拟与少数关键函数定义类之外，GCC 4.6.3 (g++ -O3)， ICC 13.1.0 (icpc -O3);将内联添加到临界点导致GCC代码加速6%)。

因此，如果你将GCC 4.6限定为现代编译器，那么如果你编写CPU密集型任务，并且知道瓶颈在哪里，内联指令仍然很重要。

实际上，几乎从来没有。你所做的只是建议编译器将给定的函数内联(例如，替换对该函数的所有调用/w它的函数体)。当然，这不能保证:编译器可能会忽略该指令。

编译器通常会很好地检测和优化这样的事情。

在进行模板特化时，仍然需要显式内联函数(如果特化在.h文件中)