f2cpp：将Fortran老代码源码级转换为C++的工程实践指南

简介：f2cpp 是一款面向科学计算与软件迁移场景的开源工具，核心功能是把 Fortran 77 程序转换为 C++ 代码，适合需要将老旧数值计算代码库现代化改造的科研人员与工程师。它由 Python 编写，相比传统 f2c 转换器，生成的 C++ 代码可读性更好，便于后续理解与维护。资源包共 11 个文件，以 7 个 py 脚本为主体，承担转换逻辑、正则处理、格式化与 IO 替换等职责，另含 2 个 doc 说明文档、1 个 sh 启动脚本和 1 个 i 接口文件，压缩包约 48KB，轻量易部署。目前已有 978 人学习下载。借助该工具，读者可快速搭建 Fortran 到 C++ 的迁移流程，理解数组处理、common blocks 等特性的适配思路，并基于开源脚本自行扩展改进，为老代码融入现代 C++ 项目提供可行路径。

1. 从 f2cpp 说起：一个把 Fortran 老代码搬进 C++ 工程的开源工具

手里有一份跑了十几年的 Fortran 数值计算代码，想塞进现在的 C++ 项目里，这事听着简单，做起来能把人磨到没脾气。f2cpp 这个开源项目就是冲着这个场景来的——它做的是 Fortran 到 C++ 的源码级转换，不是调库、不是进程间通信，而是把.f/.f90文件翻译成能编译的 C++ 源码。适合谁用？手里有历史 Fortran 资产、又不想在构建系统里维护两套编译链的团队；也适合想把某个经典数值算法从 Fortran 移植到现代 C++ 工程里、但不想手工重写一遍的开发者。它解决的核心问题就一个：让 Fortran 代码以 C++ 的身份继续活着，而不是被重写或者被隔离在一个单独的.so里靠extern "C"硬接。开源软件的好处在这里体现得很直接——转换规则、映射表、边界处理逻辑全在源码里摆着，遇到不支持的语法可以自己改，不用等官方排期。

2. 转换原理与工程结构：f2cpp 到底怎么把 Fortran 变成 C++

2.1 源码级转换和链接级复用的本质区别

很多人第一反应是“Fortran 编译成静态库，C++ 那边声明一下不就行了”。这条路能走通，但代价在后面：构建系统要同时挂 gfortran 和 g++，交叉编译时工具链翻倍，调试时调用栈跨语言跳转，符号名还得处理 name mangling。f2cpp 走的是另一条路——在源码层面做转换，输出纯 C++ 文件，之后整个工程只认 C++ 编译器。代价是转换过程本身有信息损耗，比如 Fortran 的数组语义、隐式类型规则、EQUIVALENCE这种老特性，不可能百分之百无损映射。所以选型时要先想清楚：你要的是“能编译能跑”，还是“逐位一致”。前者 f2cpp 够用，后者得逐段核对数值行为。

常见做法是先用 f2cpp 做一轮批量转换，把能自动过的部分先过掉，剩下报错的、语义可疑的片段单独拎出来手工处理。这样比全手工重写快，也比硬链接干净。

2.2 仓库目录与关键文件

拿到源码包后，先别急着编译，花五分钟把目录结构看清楚，后面排错能省一半时间。典型布局如下：

rules/目录是重点。f2cpp 把很多转换决策做成了可配置规则，而不是硬编码在分析器里。比如REAL*8映射成double还是long double，INTEGER默认位宽怎么定，都能在规则文件里调。这意味着你遇到类型不匹配的编译错误时，第一反应不该是改生成的 C++，而是回头看规则表是不是没覆盖到你的写法。

2.3 构建与首次转换

依赖很轻，一个支持 C++17 的编译器加 CMake 就能起步。下面这套命令是我在干净环境里跑通的顺序：

# 克隆后进入源码根目录 cd f2cpp # 配置构建，Release 模式转换速度明显快于 Debug cmake -S . -B build -DCMAKE_BUILD_TYPE=Release # 编译，首次约一两分钟 cmake --build build -j$(nproc) # 确认可执行文件生成 ls build/f2cpp

编译产物是一个命令行工具。接着拿一个最小 Fortran 文件试水：

! demo.f90 subroutine add_arrays(a, b, c, n) integer, intent(in) :: n real*8, intent(in) :: a(n), b(n) real*8, intent(out) :: c(n) integer :: i do i = 1, n c(i) = a(i) + b(i) end do end subroutine add_arrays

转换命令：

# -i 指定输入，-o 指定输出目录 ./build/f2cpp -i demo.f90 -o out/ # 查看生成的 C++ 文件 cat out/demo.cpp

生成的 C++ 大致是数组指针加长度参数的形态，real*8对应double，do循环转成for。这里有个参数要留意：如果原代码里数组下标从 1 开始，生成的 C++ 里循环边界会做偏移处理，别看到i = 0就以为转错了，先对一遍数值结果。

2.4 类型映射与数组语义的处理

Fortran 和 C++ 在类型和数组上差异最大的几块，f2cpp 的处理策略值得单独说。类型映射基本遵循下表：

数组是坑最多的地方。Fortran 的数组是值语义、列主序，C++ 原生数组是行主序、退化成指针。f2cpp 默认把假定形状数组转成指针加维度参数，不自动做内存布局转换。也就是说，如果你的 Fortran 代码依赖列主序做矩阵运算，转出来的 C++ 直接跑结果会错。常见做法是在转换后对矩阵相关函数手工加一层索引重排，或者干脆在 C++ 侧用列主序的访问宏包一层。这一步没有银弹，必须对着数值结果验。

提示：首次转换后不要直接集成进主工程，先单独建一个测试可执行文件，用几组已知输入输出对拍，确认数值一致再往下走。

3. 把 f2cpp 接进真实工程：从单文件到批量转换

3.1 批量转换与依赖顺序

真实项目不会只有一个.f90。一个中等规模的数值库动辄几十上百个文件，模块之间还有USE依赖。f2cpp 本身不做依赖排序，你按什么顺序喂文件，它就按什么顺序转。如果 A 模块USE了 B 模块，而 B 还没转，A 的转换结果里对 B 的引用就会落空。

我一般会先扫一遍依赖关系，用脚本生成转换顺序：

# 粗略提取每个文件的 USE 语句，人工核对依赖 grep -rHi "^[[:space:]]*use " src_fortran/ > deps.txt # 按依赖从底向上排列文件列表 # 无依赖的模块排前面，被依赖的排后面 while read -r f; do ./build/f2cpp -i "$f" -o out/ done < ordered_files.txt

ordered_files.txt需要你手工整理一次，但整理完可以复用。转换完成后，检查out/下是否每个输入都有对应的.cpp和.h，缺文件通常意味着该文件里有解析器不认识的语法，工具静默跳过了。

3.2 生成代码的编译接入

转换出来的 C++ 不是拿来就能编的，头文件包含、命名空间、数组参数形态都需要微调。典型做法是给生成代码套一层薄封装，把 Fortran 风格的接口包成 C++ 工程习惯的形态：

// wrapper.h —— 手工维护的适配层 #pragma once #include <cstddef> // 对应 Fortran 的 add_arrays void add_arrays(const double* a, const double* b, double* c, std::size_t n);

// wrapper.cpp —— 调用 f2cpp 生成的实现 #include "wrapper.h" #include "demo.h" // f2cpp 生成的头 void add_arrays(const double* a, const double* b, double* c, std::size_t n) { // 生成代码用的是 int 长度参数，这里做一次收窄 add_arrays_f(a, b, c, static_cast<int>(n)); }

这样主工程只依赖wrapper.h，生成代码的变动被隔离在wrapper.cpp里。参数说明：n用std::size_t是 C++ 侧习惯，转成int是因为生成代码沿用了 Fortran 的INTEGER映射。如果数组规模可能超过int上限，得回头改规则文件把长度参数映射成int64_t，否则大数组场景会静默溢出。

3.3 用测试对拍验证数值一致性

转换对不对，不靠眼睛看代码，靠数值对拍。思路是同一组输入，分别喂给原始 Fortran 编译出的程序和转换后的 C++ 程序，比对输出。下面是一个最小对拍脚本的骨架：

#!/usr/bin/env bash # 编译原始 Fortran 版本 gfortran -O2 -o ref_bin ref.f90 main.f90 # 编译转换后的 C++ 版本 g++ -O2 -std=c++17 -o new_bin out/*.cpp main.cpp # 跑同一组输入，输出到文件后比对 ./ref_bin < input.txt > ref_out.txt ./new_bin < input.txt > new_out.txt # 用 diff 看差异，浮点输出建议先统一精度 diff ref_out.txt new_out.txt && echo "PASS" || echo "FAIL"

浮点结果不可能逐位相同，-O2下编译器重排都会引入末位差异。对拍时要么把输出精度截断到小数点后 6 位再比，要么设一个相对误差阈值。这一步是血泪经验：曾经有次转换后结果“看起来对”，集成进主工程跑了半个月才发现某个边界条件下差了千分之一，回头查就是数组下标偏移差了一位。

3.4 规则文件的定制

遇到转换报错或者语义不对，优先看rules/下对应的规则文件。比如你的代码里大量用了REAL*4，而默认规则只映射了REAL和REAL*8，那就得补一条。规则文件一般是键值对或者简单模式匹配，改完重新构建转换器即可生效。改规则比改生成代码划算，因为规则是复用的，下次批量转换自动带上。

注意：改规则文件后一定要重跑tests/下的样例，确认没有把原本正常的映射改坏。规则之间可能有优先级覆盖关系。

4. 避坑与排查：f2cpp 转换中最容易翻车的五件事

4.1 数组下标从 1 开始导致越界

现象：转换后的 C++ 程序跑起来结果全错，或者直接段错误。原因：Fortran 数组默认下标从 1 开始，f2cpp 生成的 C++ 代码如果没做偏移，访问a(1)就变成了a[1]，整体错位一格。解决：转换后重点检查所有数组访问语句，确认生成代码里是否做了-1偏移。没有的话，在规则文件里补下标调整规则，或者手工在封装层做指针偏移。

4.2 隐式类型声明被静默丢弃

现象：某些变量在 C++ 里编译报“未声明”，但 Fortran 原文件里明明能用。原因：老 Fortran 允许IMPLICIT规则，变量不声明也能用，类型由首字母推断。f2cpp 对隐式类型的处理取决于规则配置，默认可能不生成声明。解决：在 Fortran 侧先加IMPLICIT NONE把隐式变量显式化，再重新转换。这一步虽然要改原代码，但一劳永逸。

4.3 列主序与行主序混用

现象：矩阵运算结果和原 Fortran 对不上，但标量运算正常。原因：Fortran 列主序，C++ 行主序，二维数组按线性内存访问时索引计算方式不同。解决：对矩阵相关函数，要么在 C++ 侧用列主序访问宏，要么在转换后手工重排索引。不要假设 f2cpp 会自动处理内存布局。

4.4 生成代码里的符号名冲突

现象：多个 Fortran 文件转换后链接报“重复符号”。原因：Fortran 的subroutine名在各自文件里可能重名，或者转换后没有加命名空间隔离。解决：给生成代码统一加命名空间，或者在转换时用-p之类的前缀参数（视版本支持情况）给符号加前缀。封装层里用static或匿名命名空间限制可见性。

4.5 浮点常量精度丢失

现象：涉及物理常数的计算，转换后结果偏差超出预期。原因：Fortran 里1.0D0这种双精度常量，转换时如果被当成1.0f处理，精度直接掉一截。解决：检查规则文件里对D后缀常量的映射，确保转成double字面量而不是float。转换后 grep 一遍生成代码里的浮点字面量，看有没有不该出现的f后缀。

5. 进阶技巧：让 f2cpp 输出更贴近手写 C++

5.1 用后处理脚本统一代码风格

f2cpp 生成的代码风格偏机械，变量名、缩进、注释都不太像人写的。批量转换几十个文件后，直接读生成代码很痛苦。我一般会在转换后跑一遍clang-format，再配一个简单的重命名脚本，把var_1、tmp_2这类名字换成有意义的标识。这一步不影响正确性，但大幅降低后续维护成本。

# 对生成目录下所有 cpp/h 做格式化 find out/ -name "*.cpp" -o -name "*.h" | xargs clang-format -i # 统计生成代码规模，评估手工介入量 wc -l out/*.cpp | tail -1

5.2 把转换步骤固化进构建流程

如果 Fortran 源码还会更新，每次手工跑转换不现实。常见做法是在 CMake 里加一个自定义目标，源码变动时自动触发转换：

# 在 CMakeLists.txt 里加转换步骤 add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/generated/demo.cpp COMMAND f2cpp -i ${CMAKE_SOURCE_DIR}/fortran/demo.f90 -o ${CMAKE_BINARY_DIR}/generated/ DEPENDS ${CMAKE_SOURCE_DIR}/fortran/demo.f90 COMMENT "Converting Fortran to C++" ) add_custom_target(run_f2cpp DEPENDS ${CMAKE_BINARY_DIR}/generated/demo.cpp)

这样make run_f2cpp就能在源码变动后重新转换，生成文件作为后续编译目标的依赖。参数说明：DEPENDS保证只有源文件变了才重转，避免每次全量转换拖慢构建。

5.3 转换质量的快速自检清单

每次批量转换完，我会按下面这张表过一遍，五分钟能筛掉大部分低级问题：

这张表不替代完整测试，但能在集成前把明显翻车的挡掉。从那以后我每次拿到转换结果，都强制先走一遍这张表再往主工程里合，省下过好几次半夜排查的功夫。希望帮到你。

本文还有配套的精品资源，点击获取