【发布时间】:2015-08-05 18:58:44
【问题描述】:
考虑以下“现实世界”的遗留 Fortran 77 代码,根据标准,它很可能是非法的,但在现实生活中适用于各种编译器,并且如果每个子例程单独编译,则不会产生编译器或链接器警告.
subroutine a
complex z(10)
call b(z)
call r1(z)
call r2(z)
end
subroutine b(z)
complex z(10)
c ... use complex arithmetic on z
end
subroutine r1(x)
real x(2,10)
c ... do something with real and imaginary parts
c ... real parts are x(1,*)
c ... imaginary parts are x(2,*)
end
subroutine r2(x)
real x(20)
c ... do something with real and imaginary parts
end
我想使用 Fortran 90/95 模块以这种风格重新打包代码。
的幼稚方法module m
public a
private b, r1, r2
contains
subroutine a
complex z(10)
call b(z)
call r1(z)
call r2(z)
end subroutine a
subroutine b(z)
complex z(10)
c ... use complex arithmetic on z
end subroutine b
subroutine r1(x)
real x(2,10)
c ... do something with real and imaginary parts
c ... real parts are x(1,*)
c ... imaginary parts are x(2,*)
end subroutine r1
subroutine r2(x)
real x(20)
c ... do something with real and imaginary parts
end subroutine r2
end module m
不编译,因为(当然)编译器现在可以看到子例程 r1 和 r2 使用错误的参数类型调用。
我需要一些关于如何解决这个问题的想法,只需对现有代码进行最少的重写,并且不复制内存中的数据 - 数据的真实大小太大了。
【问题讨论】:
-
我的建议是在将代码从旧标准移植到现代标准时真正清理代码,除非有很强的时间限制。由于这些子例程无论如何都是私有的,因此进入它,将参数更改为复杂的。必要时将 1 个循环更改为 2 个。从长远来看,它会有所回报。
-
在理想情况下,我会同意你的观点,但是重写几十万行记录不佳的遗留代码(可以追溯到“结构化编程尚未发明”的时代)并不是一个有吸引力的选择在现实世界中。
标签: fortran fortran90 gfortran fortran77