Fortran与C/C++的混合开发。。。
最近在把一个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一下来解决问题。因为别人涉及到的问题可能和你的不 完全一致，而一点点不一样可能就使得结果差的很远了。这也体现出一个人解决一个新的问题的方法了。对我而言，我会把所有可能用到的手段和所需的资料都罗列 一下，尽可能的详尽些。然后依照是绕过问题还是直面问题的差别分成两类，先考虑绕过。如果觉得代价可接受，也可以一劳永逸的话，那么先绕过再说，因为毕竟 是一个新问题，解决和绕过相比通常是难度更大。如果不能绕过，那么就将你所有的手段按照可靠性排个序，通常，源码总是比文档可靠，而文档有总比搜来的资料 可靠。如果一样可靠度的手段，就需要考虑一下它们实施的简单程度了，比如读文档（日文文档除外，我已经被恶心够呛了...）也许会比看源码简单一些，那么 先看看文档再说。总之，我个人觉得可靠度比简单性总会更重要一些，如果一些手段，比如从网上简单搜来的方法，你觉得不可靠，那么就不要先实施，往往是绕了 半天，你发现你又回到了原点。。。
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一下来解决问题。因为别人涉及到的问题可能和你的不 完全一致，而一点点不一样可能就使得结果差的很远了。这也体现出一个人解决一个新的问题的方法了。对我而言，我会把所有可能用到的手段和所需的资料都罗列 一下，尽可能的详尽些。然后依照是绕过问题还是直面问题的差别分成两类，先考虑绕过。如果觉得代价可接受，也可以一劳永逸的话，那么先绕过再说，因为毕竟 是一个新问题，解决和绕过相比通常是难度更大。如果不能绕过，那么就将你所有的手段按照可靠性排个序，通常，源码总是比文档可靠，而文档有总比搜来的资料 可靠。如果一样可靠度的手段，就需要考虑一下它们实施的简单程度了，比如读文档（日文文档除外，我已经被恶心够呛了...）也许会比看源码简单一些，那么 先看看文档再说。总之，我个人觉得可靠度比简单性总会更重要一些，如果一些手段，比如从网上简单搜来的方法，你觉得不可靠，那么就不要先实施，往往是绕了 半天，你发现你又回到了原点。。。
posted on 2008-04-19 00:33 duguguiyu 阅读(2742) 评论(0) 编辑 收藏 举报
