这是一个永无止境的故事,反映了“互操作性和整体可移植性”的局限性(神话)。
程序应返回什么来指示“成功”,应该由谁接收值(操作系统或调用程序的进程)来定义,而不是由语言规范来定义。
但是程序员喜欢以“便携式”方式编写代码,因此他们为定义返回的符号值的“操作系统”概念发明了自己的模型。
现在,在多对多方案(许多语言用于向许多系统编写程序的情况)中,“成功”的语言约定与操作系统的约定(没有人可以授予总是相同的含义)之间的对应关系由特定目标平台的库的特定实现处理。
但是-不幸的是-这些概念在部署C语言时(主要是编写UNIX内核)时还不清楚,而千兆字节的书说“返回0表示成功”,因为这在OS上是正确的那个时候有一个C编译器。
从那时起,就如何处理这种对应关系一直没有明确的标准化。C和C ++有其自己的“返回值”定义,但没有人提供适当的OS转换(或更优的是:没有编译器文档对此有所说明)。对于UNIX-LINUX和-基于独立原因-对于Windows,如果为true,则表示成功,并且0表示成功,并且它涵盖了90%的现有“消费者计算机”,在大多数情况下-忽略返回值(因此我们可以讨论了几十年,但没人会注意到!)
在这种情况下,在做出决定之前,请问以下问题:-我是否想就我的现有情况向来电者传达一些信息?(如果我总是始终返回0…则所有内容都没有任何线索)-我的呼叫者是否对此通信有约定?(请注意,单个值不是约定:不允许任何信息表示)
如果两个答案都为“否”,则可能好的解决方案是根本不编写主return语句。(并且让编译器决定,相对于目标是否正在工作)。
如果没有约定,则0 =成功满足大多数情况(如果使用符号引入约定,则使用符号可能会出现问题)。
如果有约定,请确保使用与它们一致的符号常量(并确保平台之间的约定一致性而不是值一致性)。