Fortran Coder

标题: Fortran和C/C++混编 [打印本页]

作者: sharpcoder 时间: 2016-1-12 23:09
标题: Fortran和C/C++混编
从来没有做过混编，求助如何进行Fortran和C/C++的混编！

具体情况是这样的：

目前我们有个规模比较大的程序，是用fortran 90/95写的，大概有三四百个子程序。由于工作要求以及后续的平台规划，需要逐步将原先的fortran代码转化为c/c++代码。考虑到原始程序规模比较大，一次性改写所有子程序不太现实，目前打算逐个子程序进行修改测试。这样的话就涉及到混编的问题。

我们使用的是VS2010+IVF2011，不知道具体该怎么做？比如：整个改写过程是用c调用fortran还是fortran调用c？具体怎么调用？需要建立两个项目（分别是c和fortran）还是将所有代码建立在一个项目中？编译器、链接器如何设置？还有就是我想到个感觉比较麻烦的事情就是原来fortran代码里面的common变量不知道如何处理？

最后就是转化成c还是c++？原来的程序中没有面向对象的东西，那转化成c还是c++好一些？目前这个计算程序的界面倒是QT C++写的，不知道是否有影响或者有关系？

还请指导！先谢过！

作者: pasuka 时间: 2016-1-13 08:20
1、成熟代码的话，不用重写，直接加个interface按照iso c binding的要求，给出C的接口，方便C或C++调用
2、混合编译的话，为啥不用cmake呢？

作者: fcode 时间: 2016-1-13 09:01
你问的问题每一个都不是三言两语可以说清楚的。

ISO_C_Binding 是好的选择。详情可以看《Modern Fortran Explained》第12章。本论坛本版块有混编分类，也可以看看以前的帖子。

作者: sharpcoder 时间: 2016-1-13 09:08
本帖最后由 sharpcoder 于 2016-1-13 09:10 编辑

pasuka 发表于 2016-1-13 08:20
1、成熟代码的话，不用重写，直接加个interface按照iso c binding的要求，给出C的接口，方便C或C++调用
2、 ...

非常感谢您！

1. 因为最终是要做成商业计算软件发布，我们的只是其中一小部分，牵扯到发布要求以及平台的统一规定等等，改写c也是无奈之举，之前我们都是把fortran打包成dll或者so文件直接调用。唉！

2. cmake的话没有接触过，之前看到国外好多搞数值计算的都在用，您也提到了，我打算也学习一下。

作者: sharpcoder 时间: 2016-1-13 09:10

fcode 发表于 2016-1-13 09:01
你问的问题每一个都不是三言两语可以说清楚的。

ISO_C_Binding 是好的选择。详情可以看《Modern Fortran E ...

好的，我先去看看。非常感谢您~

主要还是完全没有思路，感觉无从下手~我先找找有没有类似的例子，这样可能上手会比较快一些~

作者: pasuka 时间: 2016-1-13 10:31

sharpcoder 发表于 2016-1-13 09:08
非常感谢您！

1. 因为最终是要做成商业计算软件发布，我们的只是其中一小部分，牵扯到发布要求以及平台的 ...

若是fortran代码技术状态冻结，那么iso c bing写interface，本质上与打包动态链接库一个路数
反之，甭纠结，勿留恋，C++推倒重来
btw，为啥fortran代码打包动态链接库的办法被否决呢？好多商业软件照样用得很欢快

作者: pasuka 时间: 2016-1-13 10:33

sharpcoder 发表于 2016-1-13 09:10
好的，我先去看看。非常感谢您~

主要还是完全没有思路，感觉无从下手~我先找找有没有类似的例子，这样可 ...

“之前我们都是把fortran打包成dll或者so文件直接调用”
-------------都是一个路数，iso c binding就是把各家fortran编译器混合编程标准给规范统一了

作者: fcode 时间: 2016-1-13 11:03
打包成 dll 或 so 就可以了，我们也是做商业化程序，经常会使用到混编，打包成 dll 是很常见的路数。
包括成熟的软件，matlab 自身，也使用了多种语言（据说有13种之多）。我们行业用到的很多专业软件，也都是多种语言书写完成的。
有一些情况不适合打包成 dll，例如害怕别人猜测 dll 接口而非法调用。此时可以使用 lib 或 obj 混编。

不管什么方式，都可以，也都应该使用 ISO_C_Binding 来规范化接口。

作者: sharpcoder 时间: 2016-1-13 15:50

pasuka 发表于 2016-1-13 10:31
若是fortran代码技术状态冻结，那么iso c bing写interface，本质上与打包动态链接库一个路数
反之，甭纠 ...

理论上是想完全推倒重来，但是考虑到代码量太大了，所以打算一个一个子程序的改，改完一个测试一个，以免最终结果出入太大。完全重来的话后续的测试也是个麻烦事~

btw，我们的代码里面有很多以前别人写的fortran库和代码，对编译器（intel，compaq，gfortran等）依赖性太高了，而且不是很稳定，所以就考虑重新安装c/c++来设计了，感觉上层的意思是想从语言开始另起炉灶了

作者: sharpcoder 时间: 2016-1-13 15:53

fcode 发表于 2016-1-13 11:03
打包成 dll 或 so 就可以了，我们也是做商业化程序，经常会使用到混编，打包成 dll 是很常见的路数。
包括 ...

还有个问题就是后续可能需要修改一些数学模型，不转c的话后续还得用到fortran，如果单独打包部分子程序为dll的话common变量又是个问题，原来的程序比较老，几乎每个子程序都用到了common，也很愁~

作者: sharpcoder 时间: 2016-1-13 15:56

fcode 发表于 2016-1-13 11:03
打包成 dll 或 so 就可以了，我们也是做商业化程序，经常会使用到混编，打包成 dll 是很常见的路数。
包括 ...

我大致看了下modern fortran explained中的第12章，有个问题就是不知道如何建立项目？fortran和c代码都放在一个项目解决方案里面吗？还是说分别建立各自的，先分别编译，然后再一起链接？不知道哪里有具体的实践例子，书里面的感觉主要讲一些偏理论的东西了。

作者: sharpcoder 时间: 2016-1-13 15:58

pasuka 发表于 2016-1-13 10:33
“之前我们都是把fortran打包成dll或者so文件直接调用”
-------------都是一个路数，iso c binding就 ...

唉，总之感觉前期技术路线没有规划好，我也是后来才逐渐接手的。

现在要改c/c++，所以打算好好规划一下路线，要不以后会越来越麻烦，后续再修改的代价也会更高了。

作者: pasuka 时间: 2016-1-13 17:55
本帖最后由 pasuka 于 2016-1-13 17:56 编辑

sharpcoder 发表于 2016-1-13 15:50
理论上是想完全推倒重来，但是考虑到代码量太大了，所以打算一个一个子程序的改，改完一个测试一个，以免 ...

1、fortran代码对编译器的依赖性言真得很低了；
2、一个一个改，搞得不伦不类，只会事倍功半，不如另开一个C++项目，这边的fortran代码只做维护
熟悉有限元软件的话，abaqus的内核就是下决心用C++重写，ANSYS的mechanical classical内核不变，重心转移到workbench平台，nastran的内核抱着fortran不放，93版的nastran源代码现在github上面就有，也没见几个人去玩，虽然有老外说编译无大问题
github和sf上面科学计算的开源程序，要么C\C++，要么python、matlab，还在坚守fortran的寥寥无几

作者: fcode 时间: 2016-1-13 18:30
书上只会讲语法如何规范接口，并不会讲具体的编辑环境的操作。
使用VS的话，Fortran和C要分别位于两个不同的工程。但可以位于同一个解决方案（当然两个解决方案也可以）

越长的代码，我是越不希望改写。因为改写会有很大的风险，很难确定在各种数据模型的情况下都能得到原来正确的结果。

混编是极好的。fortran 代码改好了，比C/C++更容易维护。

作者: sharpcoder 时间: 2016-1-13 22:03

pasuka 发表于 2016-1-13 17:55
1、fortran代码对编译器的依赖性言真得很低了；
2、一个一个改，搞得不伦不类，只会事倍功半，不如另开一 ...

嗯嗯，明白，确实感觉非常麻烦啊~

其实研究了一天，我的感觉就是用c/c++完全重写可能比改要稳妥一些，毕竟重新设计是个独立的体系。我在考虑是不是说服一下决策层改变方案。。。

作者: sharpcoder 时间: 2016-1-13 22:05

fcode 发表于 2016-1-13 18:30
书上只会讲语法如何规范接口，并不会讲具体的编辑环境的操作。
使用VS的话，Fortran和C要分别位于两个不同 ...

我们的代码确实比较长，仅有效行数就超十万了，所以完全重新成本会非常高，混编也有很多不好处理的问题，看来还是得慎重考虑下怎么弄比较合适。。。

作者: sharpcoder 时间: 2016-1-13 22:12

pasuka 发表于 2016-1-13 17:55
1、fortran代码对编译器的依赖性言真得很低了；
2、一个一个改，搞得不伦不类，只会事倍功半，不如另开一 ...

我们主要是做一些热工水力计算，感觉现在的程序走c/c++的路线还是比较多，而且一些最新的模型库、计算库之类的也很少用fortran了，所以考虑自己的程序还是转c/c++，当然也是趁着现在我们还有开发时间。

github和sourceforge确实不错，我们倒是给忽略了（主要还是公司不能上外网，很悲剧），回头去找找一些现成的东西用用，非常感谢提醒！

作者: pasuka 时间: 2016-1-14 08:30

sharpcoder 发表于 2016-1-13 22:05
我们的代码确实比较长，仅有效行数就超十万了，所以完全重新成本会非常高，混编也有很多不好处理的问题， ...

时代在进步，不能抱残守缺，以前十万行的fortran77代码，用C++重写可能二万行足矣，换成matlab或许5000就行，因为数值计算领域有很多现成饭可以吃

欢迎光临 Fortran Coder (http://bbs.fcode.cn/)