省略返回0

当C或C++程序到达main结尾时，编译器将自动生成返回0的代码，因此不需要将返回值设置为0；明确地在main的末尾。

注意：当我提出这个建议时，后面几乎总是两种评论中的一种：“我不知道。”或“这是坏建议！”我的理由是，依赖标准明确支持的编译器行为是安全和有用的。对于C，自C99以来；见ISO/IEC 9899:1999第5.1.2.2.3节：

[…]从初始调用返回到主函数相当于用主函数返回的值作为其参数调用退出函数；到达终止主函数的}返回值0。

对于C++，自1998年第一个标准以来；见ISO/IEC 14882:1998第3.6.1节：

如果控件到达main的结尾而没有遇到return语句，则效果是执行return 0；

从那时起，两种标准的所有版本（C99和C++98）都保持了相同的想法。我们依赖于C++中自动生成的成员函数，很少有人编写显式返回；void函数末尾的语句。反对省略的理由似乎归结为“看起来很奇怪”。如果像我一样，你对C标准更改的原因感到好奇，请阅读这个问题。还要注意，在20世纪90年代初，这被认为是“草率的做法”，因为当时这是一种未定义的行为（尽管得到广泛支持）。

此外，C++核心指南包含省略返回0的多个实例；在main结尾，没有编写显式返回的实例。尽管该文件中还没有关于这一特定主题的具体准则，但这似乎至少是对这一做法的默认认可。

所以我主张省略它；其他人不同意（通常是激烈的！）在任何情况下，如果你遇到省略了它的代码，你会知道它是由标准明确支持的，你也会知道它的含义。

main的返回值指示程序如何退出。正常出口由main的0返回值表示。异常退出是由非零返回发出的信号，但对于如何解释非零代码没有标准。正如其他人所指出的，void main（）是C++标准所禁止的，不应该使用。有效的C++主签名是：

int main(void)

and

int main(int argc, char **argv)

相当于

int main(int argc, char *argv[])

还值得注意的是，在C++中，int main（）可以不带return语句，此时默认返回0。C99项目也是如此。是否返回0；是否应被省略值得商榷。有效的C程序主签名的范围要大得多。

效率不是主要功能的问题。根据C++标准，只能输入和离开一次（标记程序的开始和终止）。对于C，允许重新输入main（），但应避免。

在C中，C11标准第5.1.2.2.1节（强调矿井）：

应使用返回类型int和no来定义参数：int main（void）｛/*…*/｝或者使用两个参数（这里称为argc和argv可以使用任何名称，因为它们是所在函数的本地名称声明）：int main（int argc，char*argv[]）｛/*…*/｝

然而，对于像我这样的初学者来说，一个抽象的例子可以让我掌握它：

在程序中编写方法时，例如int read_file（char filename[LEN]）；，然后，作为此方法的调用方，您希望知道一切是否顺利（因为可能会发生故障，例如找不到文件）。通过检查方法的返回值，您可以知道一切是否顺利，这是该方法向您发出成功执行（或失败）的信号，并让调用者（例如，在主方法中）决定如何处理意外失败的机制。

现在想象一下，我为一个用于更复杂系统的微机构编写了一个C程序。当系统调用微机制时，它想知道一切是否按预期进行，以便能够处理任何潜在的错误。如果C程序的主方法返回void，那么调用系统如何知道其子系统（微机制）的执行？它不能，这就是main（）返回int的原因，以便向调用方传达成功（或失败）的执行。

换句话说：

原因是主机环境（即操作系统（OS））需要知道程序是否正确完成。如果没有int兼容类型作为返回类型（例如void），则“返回到主机环境的状态未指定”（即大多数操作系统上的未定义行为）。

省略返回0

当C或C++程序到达main结尾时，编译器将自动生成返回0的代码，因此不需要将返回值设置为0；明确地在main的末尾。

注意：当我提出这个建议时，后面几乎总是两种评论中的一种：“我不知道。”或“这是坏建议！”我的理由是，依赖标准明确支持的编译器行为是安全和有用的。对于C，自C99以来；见ISO/IEC 9899:1999第5.1.2.2.3节：

[…]从初始调用返回到主函数相当于用主函数返回的值作为其参数调用退出函数；到达终止主函数的}返回值0。

对于C++，自1998年第一个标准以来；见ISO/IEC 14882:1998第3.6.1节：

如果控件到达main的结尾而没有遇到return语句，则效果是执行return 0；

从那时起，两种标准的所有版本（C99和C++98）都保持了相同的想法。我们依赖于C++中自动生成的成员函数，很少有人编写显式返回；void函数末尾的语句。反对省略的理由似乎归结为“看起来很奇怪”。如果像我一样，你对C标准更改的原因感到好奇，请阅读这个问题。还要注意，在20世纪90年代初，这被认为是“草率的做法”，因为当时这是一种未定义的行为（尽管得到广泛支持）。

此外，C++核心指南包含省略返回0的多个实例；在main结尾，没有编写显式返回的实例。尽管该文件中还没有关于这一特定主题的具体准则，但这似乎至少是对这一做法的默认认可。

所以我主张省略它；其他人不同意（通常是激烈的！）在任何情况下，如果你遇到省略了它的代码，你会知道它是由标准明确支持的，你也会知道它的含义。

接受的答案似乎是针对C++的，所以我想添加一个与C相关的答案，这在一些方面有所不同。ISO/IEC 9899:1989（C90）和ISO/IEC 9899:1999（C99）之间也进行了一些更改。

main（）应声明为：

int main(void)
int main(int argc, char **argv)

或同等产品。例如，int main（int argc，char*argv[]）等同于第二个。在C90中，int返回类型可以省略，因为它是默认值，但在C99和更高版本中，不能省略int返回类型。

如果实现允许，main（）可以用其他方式声明（例如，int main（int argc，char*argv[]，char*envp[]）），但这会使程序实现被定义，不再严格遵守。

标准为返回定义了三个严格一致的值（即，不依赖于实现定义的行为）：0和EXIT_SUCCESS表示成功终止，EXIT_FAILURE表示失败终止。任何其他值都是非标准的，并定义了实现。在C90中，main（）必须在末尾有一个显式返回语句，以避免未定义的行为。在C99和更新版本中，可以省略main（）中的return语句。如果您这样做了，main（）完成了，则会有一个隐式返回0。

最后，从标准的角度来看，从C程序递归调用main（）并没有错。

这里有一个关于返回代码用法的小演示。。。

当使用Linux终端提供的各种工具时，可以使用返回代码，例如在过程完成后进行错误处理。假设存在以下文本文件myfile：

这是一些示例，以检查grep的工作原理。

执行grep命令时，将创建一个进程。一旦它通过（并且没有中断），它将返回一些介于0和255之间的代码。例如：

$ grep order myfile

如果你这样做

$ echo $?
$ 0

您将获得0。为什么？因为grep找到了匹配项并返回了退出代码0，这是成功退出的通常值。原因可能在于简单检查是否一切正常的布尔性质。对0（布尔值假）的简单否定返回1（布尔值真），这可以在if-else语句中轻松处理。

让我们再次检查它，但不在文本文件中，因此不会找到匹配项：

$ grep foo myfile
$ echo $?
$ 1

由于grep未能将标记“foo”与文件内容匹配，因此返回代码为1（这是发生故障时的常见情况，但如上所述，您有很多值可供选择）。同样，如果我们将其放在简单的布尔上下文中（一切正常与否），则否定1（布尔值为真）会产生0（布尔值假），这同样可以通过if-else语句轻松处理。当涉及布尔值时，任何不是0的值都被视为等同于1（因此，在用于检查是否发生错误的简单if-else语句中，2、3、4等的工作方式与使用1的情况相同）。您可以使用不同的返回值来增加错误状态的粒度。对于成功执行的状态，使用0以外的任何值都被认为是不好的做法（由于上面给出的原因）。

以下bash脚本（只需在Linux终端中键入它）虽然非常基本，但应该能给出一些错误处理的概念：

$ grep foo myfile
$ CHECK=$?
$ [ $CHECK -eq 0] && echo 'Match found'; [ $CHECK -ne 0] && echo 'No match was found'
$ No match was found

在第二行之后，由于“foo”使grep返回1，所以没有任何内容打印到终端，我们检查grep的返回代码是否等于0。第二个条件语句在最后一行回显其消息，因为由于CHECK==1，它是真的。

正如您所看到的，如果您正在调用这个和那个进程，有时需要查看它返回了什么（通过main（）的返回值），例如在运行测试时。