Io 延续行技巧，在编译时使用CPP指令调整Fortran I/O，避免冗余

在一些传统的

fortran77

子例程中，我使用位置6的延续标记

&

和一些

cpp

指令在编译时调整

I/O

，这取决于很少的参数，以避免冗余。下面看一个更简单的示例：

      open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
      read(1) a, b, c        
!
#ifdef _READMORE                                             
     &       ,d, e                                        
#endif                                                        
!                                                             
      close(1)                                                    

现在，经过一些

f90

重构（基本上，把几乎所有的东西都放在

模块中

），我正在努力重现上述行为，即当且仅当定义了

\u READMORE

时，读取

d

和

e

，由于第一行末尾出现意外的

&

，因此我尝试的第一个解决方案（如下所示）无法按预期工作，如果未定义

\u READMORE

：

open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
  read(1) a, b, c &        
!
#ifdef _READMORE                                             
         ,d, e                                        
#endif                                                        
!                                                             
close(1)                                                    

有人能告诉我完成这项任务的最佳方法是什么吗

---

如果建议的解决方案仍然依赖于这种延续行技巧并保持向后兼容性，这将是值得注意的。

到目前为止，我发现的唯一解决方法是再添加一条

read

语句（附带许多副作用）：

完全避免上面的续行技巧。但是，如果我没有记错，当定义了

\u READMORE

时，读取原始

Fortran 77

子例程编写的文件将失败，因为每个

读/写

语句都会添加一个换行：

---

不幸的是，我有很多这样的文件，我不想以这种方式重写它们。

我会选择显式版本：

open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
!
#ifdef _READMORE                                             
  read(1) a, b, c &        
         ,d, e                                        
#else
  read(1) a, b, c
#endif                                                        
!                                                             
close(1)   

---

如您所见，我还尝试在

&

续行下方添加注释行（以防万一

\u READMORE

未定义），但正如预期的那样，这被忽略。无论如何，依靠注释行来解决问题是不可取的！XD您的第一个示例将导致读取两行，而可能不是预期的一行。是的，您是对的，这就是为什么此解决方案没有我想要的向后兼容性！。。。谢谢，这可能是最好的折衷方案，只需添加一点重复（当然是为了可读性）。尽管如此，在我看来，当你有两个（或三个）ifdef

时，它就不那么可行了，因为我实际上有（即使我在上面没有提到）。考虑到所有可能的
#ifdef
和
#ifndef
组合很快就会变成一场噩梦……想象一下嵌套的组合会是多么混乱！另一种选择（不是很好）是将需要这些构造的文件作为“固定格式Fortran”，而将其他文件作为“自由格式Fortran”。Fortran标准中有一句很好的话是“软件工具从固定格式转换为自由格式源代码很简单”……你可能是对的@albert，我想知道为什么还有这么多传统的固定格式Fortran文件！我可以将这样的（固定格式FORTRAN）子例程放在一个模块中（即.F90文件）吗？或者这些子例程需要自由格式的标准？不，它不允许混合使用自由格式和固定格式的代码（wold对于读卡器和编译程序来说也是一场噩梦）。@Holmz-什么是必需的？D线是怎么回事？
      open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
      write(1) a, b, c        
!
#ifdef _READMORE                                             
     &        ,d, e                                        
#endif                                                        
!                                                             
      close(1)                             

open(unit=1,file=opfile,status="unknown",form="unformatted")
!                                                          
!
#ifdef _READMORE                                             
  read(1) a, b, c &        
         ,d, e                                        
#else
  read(1) a, b, c
#endif                                                        
!                                                             
close(1)