我应该从 main()返回 EXIT_SUCCESS 还是0？

这是一个简单的问题，但我一直看到相互矛盾的答案: C + + 程序的主例程应该返回 0还是 EXIT_SUCCESS？

#include <cstdlib>
int main(){return EXIT_SUCCESS;}

或者

int main(){return 0;}

它们是完全一样的吗? EXIT_SUCCESS应该只与 exit()一起使用吗？

我认为 EXIT_SUCCESS会是一个更好的选择，因为其他软件可能会将0视为失败，但我也听说，如果返回 0，编译器无论如何都可以将其改变为一个不同的值。

142743 次浏览
小开

程序返回的只是一个约定。

不，我想不出任何情况下“ EXIT _ SUCCESS”不会是“0”。

就我个人而言，我建议“0”。

恕我直言。

小开

如果您使用 EXIT _ SUCCESS，您的代码将更具可移植性。

Http://www.dreamincode.net/forums/topic/57495-return-0-vs-return-exit-success/

小开

没关系，两者都是一样的。

C + + 标准语录:

如果 status 的值为0或 EXIT _ SUCCESS，则返回状态成功终止的实现定义形式。

小开

一些编译器可能会对此产生问题——在 Mac C + + 编译器上，EXIT _ SUCCESS 对我来说很好用，但是在 Linux C + + 编译器上，我必须添加 cstdlib 才能知道 EXIT _ SUCCESS 是什么。除此之外，它们都是一样的。

小开

根据定义，0是一个神奇的数字。EXIT _ SUCCESS 几乎普遍等于0，令人高兴的是。那么为什么不直接返回/退出0呢？

EXIT (EXIT _ SUCCESS) ; 意思非常清楚。

退出(0) ; 另一方面，在某些方面是违反直觉的。不熟悉 shell 行为的人可能会认为0 = = false = = bad，就像 C 中0的其他用法一样。但是，在这个特殊的情况下，0 = = 成功 = = 好。对于大多数有经验的开发人员来说，这不是问题。但是为什么要无缘无故地让新人犯错呢？

Dr-如果您的神奇数字有一个已定义的常量，那么几乎没有理由不首先使用该常量。它更容易搜索，通常更清晰，等等，它不会花费你任何东西。

小开
最佳答案

EXIT_FAILURE，无论是在 main的返回语句中，还是作为 exit()的参数，都是指示 C 或 C + + 程序失败的唯一可移植的方法。例如，exit(1)实际上可以在 VMS 上发出成功终止的信号。

如果在程序失败时要使用 EXIT_FAILURE，那么为了对称起见，在程序成功时也可以使用 EXIT_SUCCESS。

另一方面，如果程序从不发出故障信号，则可以使用 0或 EXIT_SUCCESS。两者都由标准来保证成功完成。(几乎不可能 EXIT_SUCCESS的值不是0，但是在我听说过的所有实现中，它都等于0。)

使用 0有一个小优点，即在 C 语言中不需要 #include <stdlib.h>，在 C + + 中不需要 #include <cstdlib>(如果您使用的是 return语句而不是调用 exit())——但是对于任何大型程序，您都将直接或间接地包含 stdlib。

就此而言，从1999年的标准开始，在 C 语言中，以及在所有版本的 C + + 中，到达 main()的末尾总是隐式的 return 0;，所以您可能不需要显式地使用 0或 EXIT_SUCCESS。(但至少在 C 语言中，我认为显式的 return 0;更好一些。)

(有人问到 OpenVMS。我已经很久没有使用它了，但是我记得奇数状态值通常表示成功，偶数值表示失败。C 实现将 0映射到 1，因此 return 0;表示成功终止。其他值不变地传递，因此 return 1;也表示成功终止。EXIT_FAILURE将有一个非零偶数值。)

小开

一旦开始编写可以返回无数退出状态的代码，就可以开始对所有这些状态进行 #define。在这种情况下，EXIT_SUCCESS在不是“ 神奇的数字”的情况下是有意义的。这使您的代码更具可读性，因为其他每个退出代码都将是 EXIT_SOMETHING。如果你只是编写一个程序，当它完成时返回，return 0是有效的，甚至可能更干净，因为它表明没有复杂的返回代码结构。

小开

这是一个永无止境的故事，反映了“整体互操作性和可移植性”的局限性(一个神话)。

程序应该返回什么来表示“成功”应该由接收值的人(操作系统或调用程序的进程)来定义，而不是由语言规范来定义。

但是程序员喜欢用“可移植的方式”编写代码，因此他们为定义要返回的符号值的“操作系统”的概念发明了自己的模型。

现在，在一个多对多的场景中(许多语言服务于为许多系统编写程序) ，“成功”的语言约定和操作系统约定(没有人能够保证总是相同的)之间的对应应该由一个特定目标平台的库的具体实现来处理。

但是，不幸的是，这些概念在部署 C 语言的时候并不是很清楚(主要是为了编写 UNIX 内核) ，还有千兆本书上写着“返回0意味着成功”，因为当时的操作系统使用的是 C 编译器。

从那时起，对于如何处理这种通信没有作出明确的标准化。C 和 C + + 对“返回值”有自己的定义，但是没有人给出一个正确的操作系统翻译(或者更好: 没有编译器文档说明任何关于它的内容)。0对于 UNIX-LINUX 和 Windows 来说都意味着成功，而且这个数字涵盖了90% 的现有“消费电脑”，在大多数情况下，忽略了返回值(所以我们可以讨论几十年，但是没有人会注意到

在这个场景中，在做出决定之前，问下面这些问题: - 我是否有兴趣向我的来电者传达一些关于我的存在？(如果我总是返回0... ... 所有事情背后没有线索) 我的听众对这种交流有什么意见吗？(注意，单个值不是约定: 它不允许任何信息表示)

如果这两个答案都是否定的，那么最好的解决方案可能就是根本不写 main return 语句。(并且让编译器来决定，对于目标是否工作)。

如果没有约定0 = 成功满足大多数情况(使用符号可能是有问题的，如果他们引入一个约定)。

如果约定已经到位，确保使用与它们一致的符号常量(并确保平台之间的约定一致性，而不是价值一致性)。

小开

你可以不返回任何东西。

它是 好吧(比雅尼·斯特劳斯特鲁普是这样说的...) ，不显式地从 main()函数返回任何东西。如果你的操作系统需要一个返回值，编译器会处理这些事情。

这并不影响 @ Keith Thompson或 @ EmilioGaravaglia在答案中关于不同可能返回值的情况的讨论，也不影响了解程序的返回值是如何解释的等等。


提交答案