【问题标题】:This FORTRAN code shouldn't compile. Is there a reason why it does?此 FORTRAN 代码不应编译。这样做有什么原因吗?
【发布时间】:2014-12-05 17:42:48
【问题描述】:

以下代码可以编译,但我认为它不应该编译。如您所见,输出是垃圾。

这是一个在我从事的大型项目中让我难以忍受的事情的最小失败示例。

我的问题是 - 为什么编译器不抱怨?这是编译器限制,还是某种“预期行为”,我错过了什么?

我使用的是 gfortran 4.6.3。

module dataModule
    integer :: datum1 = int(1)
    integer :: datum2 = int(2)    
end module dataModule

program moduleTest
    use dataModule, only: datum1

    write(*,*) "datum 1 is", datum1
    write(*,*) "datum 2 is", datum2

end program moduleTest

示例输出:

datum 1 is           1
datum 2 is  4.58322689E-41

【问题讨论】:

  • 你错过了implicit none。没有它,代码是非常有效的,并且允许输出。
  • 书中最古老的把戏:)
  • 啊当然!多谢你们。实际上比这更糟糕,我在(非常旧的!)代码中编辑的模块具有 IMPLICIT REAL*8 (a-h,o-z)

标签: compilation fortran fortran90 gfortran


【解决方案1】:

您的代码有问题,而不是编译器。 如果 datum2 被使用关联,尽管only 子句和if datum2 的显式初始化被忽略,那么是的,那将是一个顽皮的编译器。

不过,答案要平凡得多。

datum2 不使用关联:在没有implicit none 的情况下,它是主程序中的隐式类型变量。 “垃圾”来自这样一个事实,即在引用其值之前未通过初始化或赋值定义它,并且它是隐式(默认)真实的。编译器不需要在编译(或运行)时检测此错误。

【讨论】:

  • 这是什么,@francescalus?在评论中回答数月后回来获得“已接受的答案”互联网积分?哦,那么继续;)我了解到,使用古代 Fortran 代码的一个陷阱是它没有任何implicit nones,而且生命太短,无法挑选并正确输入所有变量。所以我用 C++ 重写了它。
  • 奇怪的是,我在浏览器的选项卡中打开了这个问题六个月。因此,可能会整理互联网和我的桌面的“未答复”部分;)。
猜你喜欢
  • 2015-08-10
  • 1970-01-01
  • 1970-01-01
  • 2019-07-08
  • 2019-02-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-07-06
相关资源
最近更新 更多