1

我一直认为 fortran 将实体“通过引用”传递给虚拟参数。然后我得到了这个答案(答案的实际论点是相关的,但不是这个)

该标准从不指定这一点,并且确实非常规避此类规范。尽管您的误解是一个常见的误解,但即使在大多数较旧的编译器中,它也不是严格准确的,尤其是在启用优化的情况下。严格的按引用传递会扼杀许多常见的优化。

使用最近的标准,在某些情况下几乎不允许引用传递。该标准在其规范性文本中没有使用这些词,但有些事情通过引用传递是不切实际的。

当你开始研究指针之类的东西时,假设一切都是按引用传递的错误将开始变得比以前更加明显。你必须放弃这种误解,否则很多事情会让你感到困惑。

我认为其他人已经充分回答了帖子的其余部分。有些人也提到了上述观点,但我想强调一下。

请参阅此处了解归属

根据这个答案,标准中没有任何内容指定数据如何从调用者传送到被调用者。实际上,应该如何从实际使用它的角度来解释它(不管编译器如何实现标准所产生的实际效果),特别是在 intent() 规范方面?

编辑:我想澄清我的问题。我想了解的是标准期望您在执行呼叫时如何工作。鉴于标准未定义用于传递实体的实际编译器策略,原则上(根据标准)您不能期望将参数传递给函数实际上将表现为“按引用传递”,其所有相关的副作用,因为此行为取决于编译器和优化。因此,我假设该标准强加了您必须遵循的编程风格,而不管实际的实施策略如何。

4

3 回答 3

3

是的,这是真的。Fortran 标准没有为不同的 INTENT 属性指定确切的评估策略。例如,对于带有 INTENT(OUT) 的虚拟参数,某些 Fortran 编译器可以使用按引用调用或按复制调用恢复评估。

但我不明白为什么你真的需要知道使用哪种评估策略?是什么原因?我认为 Fortran 做得对。人类关注的是(高级)论证意图,计算机关注的是(低级)评估策略。“把属于人的东西交给人,把属于计算机的东西交给电脑。” N.维纳

我认为该标准包含有关不同 INTENT 属性使用的足够信息。Fortran 2003 标准最终委员会草案的“5.1.2.7 INTENT 属性”部分(PDF,5 MB)是一个很好的起点。

于 2010-10-22T12:23:38.067 回答
2

正如其他人所说,您不必知道编译器是如何工作的,只要它可以正常工作。Fortran >=90 允许您指定参数的用途:输入、输出或两者,然后编译器负责传递参数。只要编译器正确实现,使得双方(调用者和被调用者)使用相同的机制,程序员为什么要关心呢?因此,Fortran 标准试图不限制编译器编写者如何实现他们的编译器,允许他们按照自己的意愿进行设计和优化。

就编程风格而言,确定过程参数的用途,并以适当的意图声明它们。然后,例如,如果您不小心尝试修改过程中的 intent(in) 参数,编译器将发出错误消息,防止您犯此错误。它甚至可能在发出目标代码之前执行此操作,因此实际的参数传递机制与强制执行语言的这一要求无关。

C 是一种低级语言,出于各种原因,程序员需要在按值传递或按引用之间进行选择。但是对于诸如科学编程之类的问题,这是必须控制的不必要的方面。它在嵌入式或设备驱动程序编程中可能是必不可少的。

如果出于某种原因您必须控制参数传递机制,例如与另一种语言的接口,Fortran 2003 提供了 ISO C 绑定(它已被广泛实施)。有了这个,你可以匹配参数传递的 C 方法。

于 2010-10-22T15:15:09.767 回答
1

我不确定我是否理解您的问题,但一种看待事物的方式是,只要编写符合标准的代码,就不需要关心如何实现参数传递。编译器确保(当然,排除编译器错误)参数以符合标准的方式传递。

现在,如果您使用 C 互操作之类的技巧,例如通过比较参数地址,您可能能够确定编译器是否在某些特定情况下使用按引用传递、复制输入/复制输出或其他方式。但一般来说,那时你已经超出了标准的范围,所有的赌注都没有了。

于 2010-10-22T12:26:12.353 回答