Fortran和C/C++混编

sharpcoder

从来没有做过混编，求助如何进行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++写的，不知道是否有影响或者有关系？

还请指导！先谢过！

sharpcoder

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

非常感谢您！

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

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

sharpcoder

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

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

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

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

sharpcoder

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

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

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

sharpcoder

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

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

sharpcoder

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

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

sharpcoder

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

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

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

sharpcoder

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

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

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

sharpcoder

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

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

sharpcoder

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

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

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