打包成 dll 或 so 就可以了，我们也是做商业化程序，经常会使用到混编，打包成 dll 是很常见的路数。
包括 ...
我大致看了下modern fortran explained中的第12章，有个问题就是不知道如何建立项目？fortran和c代码都放在一个项目解决方案里面吗？还是说分别建立各自的，先分别编译，然后再一起链接？不知道哪里有具体的实践例子，书里面的感觉主要讲一些偏理论的东西了。 pasuka 发表于 2016-1-13 10:33
“之前我们都是把fortran打包成dll或者so文件直接调用”
-------------都是一个路数，iso c binding就 ...
唉，总之感觉前期技术路线没有规划好，我也是后来才逐渐接手的。
现在要改c/c++，所以打算好好规划一下路线，要不以后会越来越麻烦，后续再修改的代价也会更高了。 本帖最后由 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的寥寥无几
书上只会讲语法如何规范接口，并不会讲具体的编辑环境的操作。
使用VS的话，Fortran和C要分别位于两个不同的工程。但可以位于同一个解决方案（当然两个解决方案也可以）
越长的代码，我是越不希望改写。因为改写会有很大的风险，很难确定在各种数据模型的情况下都能得到原来正确的结果。
混编是极好的。fortran 代码改好了，比C/C++更容易维护。 pasuka 发表于 2016-1-13 17:55
1、fortran代码对编译器的依赖性言真得很低了；
2、一个一个改，搞得不伦不类，只会事倍功半，不如另开一 ...
嗯嗯，明白，确实感觉非常麻烦啊~
其实研究了一天，我的感觉就是用c/c++完全重写可能比改要稳妥一些，毕竟重新设计是个独立的体系。我在考虑是不是说服一下决策层改变方案。。。 fcode 发表于 2016-1-13 18:30
书上只会讲语法如何规范接口，并不会讲具体的编辑环境的操作。
使用VS的话，Fortran和C要分别位于两个不同 ...
我们的代码确实比较长，仅有效行数就超十万了，所以完全重新成本会非常高，混编也有很多不好处理的问题，看来还是得慎重考虑下怎么弄比较合适。。。 pasuka 发表于 2016-1-13 17:55
1、fortran代码对编译器的依赖性言真得很低了；
2、一个一个改，搞得不伦不类，只会事倍功半，不如另开一 ...
我们主要是做一些热工水力计算，感觉现在的程序走c/c++的路线还是比较多，而且一些最新的模型库、计算库之类的也很少用fortran了，所以考虑自己的程序还是转c/c++，当然也是趁着现在我们还有开发时间。
github和sourceforge确实不错，我们倒是给忽略了（主要还是公司不能上外网，很悲剧），回头去找找一些现成的东西用用，非常感谢提醒！ sharpcoder 发表于 2016-1-13 22:05
我们的代码确实比较长，仅有效行数就超十万了，所以完全重新成本会非常高，混编也有很多不好处理的问题， ...
时代在进步，不能抱残守缺，以前十万行的fortran77代码，用C++重写可能二万行足矣，换成matlab或许5000就行，因为数值计算领域有很多现成饭可以吃
页:
1
[2]