这是一个无休止的故事,反映了“互操作性和可移植性最重要”的限制(和神话)。
程序返回什么值来表示“成功”,应该由接收该值的人(操作系统或调用程序的进程)定义,而不是由语言规范定义。
但程序员喜欢以“可移植的方式”编写代码,因此他们发明了自己的模型来定义“操作系统”概念的符号返回值。
现在,在一个多对多的场景中(许多语言用于编写针对许多系统的程序),语言约定的“成功”与操作系统约定的“成功”之间的对应关系(没有人可以保证始终相同)应该由特定目标平台的库的具体实现处理。
但很不幸,当 C 语言部署时(主要用于编写 UNIX 内核),这些概念并不那么清晰,因此有大量的书籍写着“return 0 表示成功”,因为在当时有 C 编译器的操作系统上是正确的。
从那时起,就从未对如何处理这种对应关系进行清晰的标准化。C 和 C++ 有它们自己的“返回值”定义,但没有人保证有适当的操作系统翻译(或者更好地说:没有编译器文档说明它)。如果UNIX-LINUX和Windows的话,0表示成功,并且这覆盖了90%的现有“消费计算机”,在大多数情况下,它们忽略了返回值(因此我们可以讨论数十年,但从未有人会注意到!)
在这种情况下,在做出决定之前,请问以下问题:
- 我是否有兴趣向我的调用方传达一些关于我的存在的信息? (如果我总是返回 0 ...就没有关于全部内容的线索)
- 我的调用方是否有关于此通信的约定? (请注意,单个值不是一种约定:这不允许任何信息表示)
如果这两个答案都是否定的,则最好的解决方法可能是根本不编写主返回语句。(并让编译器根据它所工作的目标来决定)。
如果没有约定规定,0=成功可以满足大多数情况(使用符号可能存在问题,如果它们引入了一种约定)。
如果已有约定,请确保使用与其相一致的符号常量(并确保平台间的约定一致性,而不是值的一致性)。