Fortran 分配声明和 SAVE 属性陷阱答案

【问题标题】：Fortran assignment on declaration and SAVE attribute gotchaFortran 分配声明和 SAVE 属性陷阱
【发布时间】：2010-07-28 12:21:19
【问题描述】：

在 fortran 95 中，如果在声明时分配变量

integer :: var = 0

相当于

integer, save :: var = 0

因此变量在例程执行后被保留（相当于C语言中的static）并且在再次调用时不会重新初始化。这种（恕我直言危险）行为背后的基本原理/技术问题是什么？

【问题讨论】：

为了完整起见，让我提一下，在 Fortran 2003 标准中，您提到的这一点在 C1107 中有所介绍：“如果出现指定了组件初始化 (R444) 的类型的对象在模块的规范部分并且没有 ALLOCATABLE 或 POINTER 属性，该对象应具有 SAVE 属性。"。
@Alexandros Gezerlis - 对，但他在问“为什么”他们这样做，现在我理解了他的问题，我也有同样的问题:)。
我知道，这就是为什么我没有发布这个作为答案。

标签： fortran

【解决方案1】：

我不认为这种行为背后有什么理由。

但据我所知，Stefano，您使用了错误的术语。在您的代码中没有赋值语句只有使用初始化表达式 (0) 进行的变量 (var) 初始化。

integer :: var = 0 ! type declaration & initialization

integer :: var ! type declaration
var = 0        ! assignment

看来这只是委员会的设计决定。如果我们有这样的表达式（在类型声明语句中带有等号），它是初始化而不是赋值。并且在程序（而不是程序）执行期间初始化只发生一次。

但是，这样的决定可能有一些历史原因。看看this 线程。

今天这种行为是危险的，因为许多其他广泛使用的语言遵循关于初始化/赋值的另一种约定。

【讨论】：

如果这是一个经过深思熟虑的设计决策，我是否应该发布一个问题“Fortran 委员会成员在决策会议期间允许吸烟什么？” ：）严重地。我不认为他们搞砸了这么严重，所以一定有一个原因，可能是出于兼容性或技术问题。为了自己的利益而做出设计决定似乎太奇怪了。
@Stefano：也可能有一些历史原因，不吸烟。 =) 阅读此主题：rhinocerus.net/forum/lang-fortran/…
我认为你恰到好处！请编辑您的答案以包含链接。
链接现在断开了。这篇文章的主旨是什么？
@Wildcat，J3 总是有理由改变 Fortran 标准。您可以在j3-fortran.org/doc/year 找到至少可以追溯到 1987 年的文档。如果您看（我不会），我怀疑您会发现 real :: x = 42. 旨在替换 real x 后跟 data /x/42. 的两个语句。（data 语法可能在这里搞砸了，因为我很少使用 data 语句。）因此，初始化表达式的语义继承自 data 语句。

【解决方案2】：

许多旧的 FORTRAN 77 和更早的编译器静态分配所有变量。许多程序员依赖于这种行为——从技术上讲，这在他们的程序中是一个错误，因为除非他们在声明中使用“SAVE”限定符（或在每个过程中添加一个普通的 SAVE 语句），否则变量的值在重新进入时是未定义的程序。但由于在那些日子里，程序往往与特定的平台和编译器绑定多年，程序员就侥幸逃脱了。这是将遗留 FORTRAN 77 代码移植到现代 Fortran >= 90 编译器的一个非常常见的“陷阱”。大多数编译器都提供了编译时开关来恢复这种行为，例如 gfortran 的 fno-automatic 选项。委员会很可能认为在声明中初始化的变量很可能需要 SAVE 属性——在我看来，这是一个合理的设计决策。我认为与其他语言最大的不同，也是多语言程序员最容易混淆的地方是初始化只进行一次。

【讨论】：

Fortran 77 标准没有指定是否会发生重新初始化。我使用了两种编译器；没有 SAVE 的初始化实践是不可移植的。我记得看到一个声明，委员会认为单独的分配清楚地处理了重新初始化的情况，并允许应用或删除 SAVE 限定符而不影响结果，而使用另一种选择实现的初始化一次行为不会干净在标准中。