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

F.5:如果一个函数非常小并且对时间要求很高，那么就内联声明它

原因:一些优化器在没有程序员提示的情况下很擅长内联，但不要依赖它。测量!在过去40年左右的时间里，我们一直被承诺在没有人类提示的情况下，编译器可以比人类更好地内联。我们还在等待。指定inline(在类定义中编写成员函数时显式或隐式)可以鼓励编译器更好地完成工作。

来源:https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html Rf-inline

有关示例和异常，请访问源代码(参见上面)。

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

2)。看到# 1。

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

Inline关键字请求编译器用函数体替换函数调用，它首先计算表达式，然后传递。它减少了函数调用开销，因为不需要存储返回地址，函数参数也不需要堆栈内存。

使用时间:

提高绩效 减少呼叫开销。 因为它只是对编译器的请求，所以某些函数不会被内联 *大功能 有太多条件参数的函数 递归代码和带有循环的代码等等。

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

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

除非您正在编写一个库或有特殊的原因，否则您可以忘记内联，而是使用链接时间优化。它消除了函数定义必须在头文件中才能考虑跨编译单元进行内联的要求，这正是内联所允许的。

(但请参阅为什么不使用链接时间优化?)