功能原型设计的优点

时间:2013-01-22 14:42:37

标签: c function-prototypes

在互联网上进行了半小时的研究之后,我找不到任何有关功能原型设计优势的合理讨论。

我在Java / Android中管理,并开始了C课程。与我之前的经验相比,原型设计看起来很麻烦,我想知道它在2013年仍然存在的原因。

我明白里奇和朋友的生活更加艰难;但是,今天编写的编译器可以在第一次传递中生成函数列表,然后使用该函数列表执行常规操作,因为当前编译器将使用头文件。

它可能无法持久,只是因为向后兼容性。创建一个可以在当前操作模式和我刚才描述的假设新模式之间切换的编译器是可行的,具体取决于显示的代码。

如果原型设计仍然存在,那么它必须对程序员感兴趣,而不是编译器程序员。我是对还是错 - 在哪里可以找到有关功能原型设计与无原型设计优势的合理讨论?

2 个答案:

答案 0 :(得分:8)

你忘了在C中你可以调用你没有来源的函数

C支持代码的二进制分发,这对于(商业)库来说非常常见。

您将获得一个标头,用于声明API(所有函数和数据类型)以及.lib(或您平台使用的任何文件)文件中的代码。对于所有C的标准库来说通常都是这种情况;您并不总是将源代码提供给编译器供应商的库,但您当然仍必须能够调用这些函数。

为了实现这一点,C编译器在处理代码时必须具有声明,因此它可以为调用生成适当的参数,当然也可以正确处理任何返回值。

仅仅依靠你的来源是不够的,因为如果你这样做了

GRAPHICSAPI_SetColorRGB(1, 1, 1);

但实际声明是:

void GRAPHICSAPI_SetColorRGB(double red, double green, double blue);

如果没有原型,编译器无法将int参数神奇地转换为double。当然,拥有原型可以错误地检查调用是否有意义,这是非常有价值的。

答案 1 :(得分:3)

让编译器首先查看所有源文件以了解所有函数原型的有趣想法。

然而

  • 库(目标代码)需要在某个地方声明它们,这就是包含存在的原因

此外,我发现grep 包含作为“自由文本”非常方便,例如

grep alloc /usr/includes/*