最近在把一个Fortran的程序封成模块整合进一个C++的平台中。平生第一次做fortran,也算是第一次正二八经的做二进制的混合开发。简单写一些,算为前一段工作做个总结。。。
Fortran90与C++的整合,可以基于静态链接。就是都生成obj,然后link在一起。当然也可以是动态链接的,把Fortran打成dll,然 后在C++中调用(windows下...)。当然,这都不会是本质性的问题,你可以根据需求自行抉择。在不同二进制模块中互调,更为关键的是ABI。说 英文的和说中文的总不能和谐的打成一片,要在一块玩就需要一些共同的语言。。。
Calling Conventions在这里显得很重要。首先就是Naming conventions,Fortran和C++的函数名解析往往是不一样的。同样你取名叫functionA的,在C++里面(extern "C")编译完了可能叫functionA_,可到了fortran里,可能会叫_functionA@4。当然,这个问题并不可怕,查一下编译器的手 册,此问题即可迎刃而解。。。
然后是Stack considerations的问题,也就是说函数栈是由调用方管理还是被调用方管理,有兴趣的可以看下这里,同时在fortran中,参数的默认传递方式不同,它默认通过传址来进行传递,这一点需要注意。。。
最后,最麻烦的问题是Argument passing protocol,一个fortran的数据在C++中应该怎么表示呢?基本数据类型这都还好,但数组呢?自定义数据类型呢?在高层一些的语言里,我们根 据串行化的方式,自动将参数序列化和反序列化进行数据转换,一切都比较水到渠成。但基于二进制的接口,调用的基础只是栈的完全匹配,一点点差池对会缪之千 里。在fortran里,数组是列优先的,这正与C++相反,需要注意。而更恶心的是,fortran的数组及其强大,可以从任何脚标起,其间隔可以是任 意的,于是乎在intel的编译器下,一个普通的一维数组的指针,需要占用32个字节的空间。所有这些,都导致参数的传递在此类开发中成为最脆弱的环节。 它们彼此只是靠着栈中信息的一致性依偎在一起,一点点编译器的改动(或者用了一个其他的编译器...),或者是两边程序数据结构的改动(对于自定义类型而 言...),都可能导致崩溃性的后果。解决这个问题,需要依靠在设计层面上解决。需要传递复杂结构的接口都不要用,用一系列方法的调用来替代单一的方法, 将简单的数据依赖转换成为接口定义的依赖。因为基本数据类型总是像黄金一样坚挺,而复杂类型数据的解析总是像股票那般不靠谱。所以我们的原则是,只选简 单,不选复杂。。。
当你做这样一件工作的时候,官方的手册和示例代码是你最好的帮手,而不要简单的依靠问人或Google一下来解决问题。因为别人涉及到的问题可能和你的不 完全一致,而一点点不一样可能就使得结果差的很远了。这也体现出一个人解决一个新的问题的方法了。对我而言,我会把所有可能用到的手段和所需的资料都罗列 一下,尽可能的详尽些。然后依照是绕过问题还是直面问题的差别分成两类,先考虑绕过。如果觉得代价可接受,也可以一劳永逸的话,那么先绕过再说,因为毕竟 是一个新问题,解决和绕过相比通常是难度更大。如果不能绕过,那么就将你所有的手段按照可靠性排个序,通常,源码总是比文档可靠,而文档有总比搜来的资料 可靠。如果一样可靠度的手段,就需要考虑一下它们实施的简单程度了,比如读文档(日文文档除外,我已经被恶心够呛了...)也许会比看源码简单一些,那么 先看看文档再说。总之,我个人觉得可靠度比简单性总会更重要一些,如果一些手段,比如从网上简单搜来的方法,你觉得不可靠,那么就不要先实施,往往是绕了 半天,你发现你又回到了原点。。。