为什么C ++中的main（）无法内联？

我在阅读C ++常见问题解答，但发现一句话。

main（）不能内联。

为什么是这样？

在C ++中，在代码中调用main函数是不合法的，因此不可能内联。

因为该标准是这样说的：

[2003: 3.6.1/3]：在程序中不得使用main函数（3.2）。main的链接（3.5）是实现定义的。声明main为嵌入式或静态的程序格式错误。名称main否则不保留。[示例：成员函数，类和枚举可以称为main，其他命名空间中的实体也可以称为main。]

为什么这么说呢？因为它试图将更多的实现留给main个人来做，所以，实现是尽可能的，并且不想通过inline在可能没有实际好处的情况下要求此处有效来限制实现。

我在委员会上的朋友证实了这一点：

inline main()本身没有任何理由不起作用。[..]我可能有一个C ++解释器，可以调用inlined main()。[..] [但是] inline/static main()是被禁止的，以期避免混乱。我很难想象，该原理将是在[此问与答]中已经说过的东西之外的任何东西。

顺便说一句，不要将inlinehint关键字与实际的内联函数混淆。您可以标记一个函数inline，但实际上可能没有内联。

因此，即使main“不能内联”的确是正确的（严格地说，这是不正确的，尽管内联会main很笨拙且毫无意义，如其他答案所述），但理论上它仍inline可以很好地支持提示关键字。

这不是出于上述原因，而是在litb的回答中：它会使事情变得复杂，没有任何实际好处。

C运行时库需要找到该符号，以便“知道”要运行的功能。

您不能直接调用main（）（在c ++中是禁止的），因此没有必要对其进行内联。

通常main()从系统init()函数中调用。因此，需要为定义一个准确的定义main()。

现在，如果我们可以使用inline该main()函数并将其包含在头文件中，那么对于每个翻译单元，都会有不同的定义main()。这是不允许的。您可以main()在namespace和中声明inline。但不是全球性的main()。

首先，您必须了解内联工作的功能

例：

 inline void f() {
     int a  = 3;
     a += 3;
     cout << a;
 }

 int main() {
      f();
      return 0;
 }

在编译器中看起来像：

 int main() {
        int a  = 3;
        a += 3;
        cout << a;
        return 0;
 }

看这个例子，你想如何使主内联？此方法立即内联。

C ++标准表示main，根据@Tomalak Geret'kal的回复，不能内联该函数。该响应讨论main了删除标准中的限制时内联函数的可能性。

内联
的定义inline关键字是对编译器的建议，可将其内容原位粘贴。一种目的是消除存在于从函数（子例程）调用和返回中的开销。

内联的重要情况是存在指向函数的指针的情况。在这种情况下，必须至少有一个该功能的静态副本。在这种情况下，链接器可以解析内联函数的“外部链接”，因为存在一个静态版本。

重要的是要注意，编译器和链接器确定是粘贴内容还是调用函数的单个实例。

还要注意的是，编译器也可以内联未编程人员未标记的功能。

内联主要功能
由于仅main允许一次调用，因此如何链接取决于编译器。标准允许内联函数的单个实例。允许编译器将inlined函数转换为对单个实例的函数调用。因此，编译器将忽略对该main函数的内联建议。

编译器和链接器必须确保仅main存在一个内联函数的实例。这是棘手的部分出现的地方，尤其是在外部链接中。确保一个实例的一种过程是让翻译具有“主”功能（无论是否内联）。 注意：调用内联函数时，允许编译器从符号表中删除该函数以进行外部链接，因为这样的想法是外部函数不会调用该函数。

总结
从技术上讲，没有什么可以阻止该main函数被内联的。的机械已存在用于将内联的函数成单实例和用于识别功能的多个实例。当存在指向内联函数的指针时，将创建一个函数的单个实例，因此它具有一个地址。该机器将满足运行时库对main具有地址的要求。在inlineformain函数的情况下，它将被忽略，但不应有任何理由阻止这种语法（除非使人感到困惑）。毕竟，已经有多余的语法案例，例如将通过值（副本）传递的参数声明为const。

“那只是我的看法，我可能是错的。” -喜剧演员丹尼斯·米勒（Dennis Miller）。

其他人指出，main在机器代码级别上不能有意义地内联的调用。那是垃圾 这将需要链接程序提供一些帮助（例如全局优化），或者需要按应用程序重新编译运行时库的一部分，但这是完全可行的，这里没有技术问题。

但是，调用的提示效果inline最好应该是内联的，与仅在控件的最高级别被调用一次的函数无关main。

唯一保证效果的inline是，以允许在两个或多个翻译单元（相同）中所定义的外部联动功能，即影响了一个定义规则。

实际上，这允许将定义放置在头文件中，并且将其放置在头文件中实际上也是保证相同定义的必要条件。

这不会使意义main，所以没有理由main要inline。

您只能定义main一次。因此，放置inline将无济于事-inline仅对您可以在程序中多次定义的功能有重要意义（所有定义都将被视为只有一个定义，并且所有定义必须相同）。

因为inline可以在程序中多次定义函数，并且inline还具有inline尽可能快地调用带标记的函数的目的，所以该标准要求inline在使用该函数的每个翻译单元中都定义函数。因此，如果inline当前翻译单元中的代码未使用该函数的定义并且该函数未使用该函数，则编译器通常会放弃该函数的定义。这样做main完全是错误的，这表明inline语义与语义main完全不兼容。

请注意，标题中的问题“为什么不能内联C ++中的main（）？” 您引用的标准声明涉及的是不同的内容。您正在询问该函数是否可以内联，这通常被理解为将被调用函数的代码完全或部分插入到调用函数中。仅标记一个函数inline并不意味着完全内联该函数。这完全是编译器的决定，当然，如果您从不调用main（并且您不能这样做），则没有任何内容可以内联。

如果您静态链接到CRT并启用了一些链接时编译内联（如MSVC那样），则可以内联它。

但这没有任何意义。它只会被调用一次，与main执行第一行之前完成的所有其他操作相比，该函数的调用开销几乎为零。

...

Aaand，这是一种强制符号仅在可执行文件中出现一次的简便方法。:)

有许多基本原因。基本上，main从运行时的基本初始化例程中调用，并且仅从那里开始。该代码（显然）是在不知道您的main内联的。现代编译器技术能够跨模块边界进行内联，但这是一项高级功能，许多较早的编译器均不支持。当然，仅当频繁调用函数时，内联的好处才存在。根据定义，main 将只被调用一次，不会更多，也不会更少。

我看到该标准是这样说的，但是真正的实际答案将很简单，就像声明添加到每个C和C ++程序的运行时必须调用可执行文件中的某个点一样。该函数应该有一个外部符号（运行时带有地址），以便链接程序可以在执行开始时找到要调用的函数。因此，您不能将其声明为inline，因为内联的编译器不会为其生成外部符号。

因为它的main（）函数开始执行，所以当代码被编译为二进制时，一切都在其main()自身中。所以你可以说，它已经内联了！

是的，在您的C ++程序中使用内联是非法的，这更多是关于语法！

对于大多数编译器/体系结构组合，main()源代码中的函数在最终二进制文件中成为合理的正常函数。这仅是因为在这些架构上很方便，而不是因为标准规定必须如此。

在受内存限制的体系结构上，许多编译器会生成平坦的二进制文件（如intex十六进制格式），而不是动态链接程序友好的容器（如elf或xcoff），它们会优化所有样板，因为这样做只会肿。有些体系结构根本不支持函数调用（在这些平台上只能使用C ++的有限子集。）

为了支持最广泛的此类架构和构建环境，该标准选择保留以下内容的语义： main()尽可能开放，以便编译器可以为最广泛的平台做正确的事。这意味着从整体上来说，该语言中的许多功能都无法应用于应用程序本身的启动和关闭。

如果您需要内联main()（或可重入，或任何精美的功能）之类的东西，您当然可以调用main函数：

inline int myMain(int argc, char **argv) { /* whatever */ }
int main(int argc, char **argv) { return myMain(argc, argv); }

内联函数默认情况下具有静态作用域。这意味着，如果我们将main（）声明为内联，则其范围将限于定义该文件的文件。但是，C启动库（由编译器供应商提供）需要“ main”成为全局符号。有些编译器允许使用链接器标志修改入口点功能（例如main）。

内联函数通常没有地址，因此没有可移植的方式来调用main，main（）需要一个可以将初始化代码跳转到的地址。内联函数应嵌入到调用函数中，如果main被内联，则应将其内联到程序的初始化代码中，该代码也不可移植。

操作系统将二进制数据加载到内存中；寻找入口点（c / c ++中的“主要”符号）；跳至入口点标签的地址。在未加载程序之前，操作系统对代码中的主要功能一无所知。