編譯器與通用性
我的筆記本上使用的是codeblocks完成fortran代碼開發(fā)的編譯器是GNU Fortran带欢。但是單位的服務(wù)器原本是Sun Solaris吧雹，編譯器是F95宵距。后來變?yōu)轺梓雔inux，在這樣一個(gè)以開源著稱的系統(tǒng)下匪凉，使用的編譯器居然是ifort蔑赘。
并不是說各個(gè)編譯器的好壞，這方面的評(píng)價(jià)會(huì)有更加專業(yè)的人來回答乡摹。我的工作沒有這么高端的需求役耕。
我遇到的問題是，身邊的同事在編碼的過程中使用了一些編譯器特有的語法聪廉，造成了后續(xù)二次開發(fā)與移植的困難瞬痘。。板熊。所以在編碼的過程中框全，我還是盡可能的選擇規(guī)范中的用法，而不是編譯器特有的用法干签。
transfer()
原來對(duì)于transfer()函數(shù)的理解津辩，一直當(dāng)做integer(4)，real這樣基本數(shù)據(jù)類型相互轉(zhuǎn)換使用。手頭上僅有的教材也是這么說的喘沿。闸度。。下面說說我是怎么用transfer()來代替union與map的蚜印。
在開發(fā)的需求中莺禁，有個(gè)這樣的場景：
- 底層模塊是用c實(shí)現(xiàn)的進(jìn)程間電文通信的一個(gè)函數(shù)庫。其中一個(gè)完成接收的接口函數(shù)
int receive(phbuff* buff) - phbuff是所有電文類型的一個(gè)總的接口窄赋。length指名有效數(shù)據(jù)data的長度哟冬，type指名了有效數(shù)據(jù)應(yīng)該安裝什么類型解析。接口文件的c是這么描述的
struct phbuff{
int length;
int type;
char data[1024]
}
- 舉個(gè)例子忆绰，在data[1024]存儲(chǔ)空間中可能含有如下A浩峡，B兩種類型數(shù)據(jù)，按照fortran的接口文件是這么描述的
type :: A
real(8) :: range
real(8) :: velocity
integer(4) :: status
end type
type :: B
integer(2) :: tid
real(8) :: pos_xyz(3)
end type
4.需要用Fortran寫一個(gè)信息接收程序较木，通過調(diào)用receive()函數(shù)完成信息的接收红符，然后根據(jù)phbuff數(shù)據(jù)結(jié)構(gòu)中的type字段區(qū)分?jǐn)?shù)據(jù)類型A/B，根據(jù)不同的數(shù)據(jù)類型采取后續(xù)的處理措施伐债。
union與map的實(shí)現(xiàn)
原來的處理方式是利用union與map预侯，將上面的數(shù)據(jù)類型A，B整合成一個(gè)總的類型峰锁，定義是這么做的：
type phdata
union
map
type(A) :: msg_map_a
end map
map
type(B) :: msg_map_b
end map
end union
end type
type unionbuff
integer(4) :: len
integer(4) :: itype
type(phdata) :: union_data
end type
使用的時(shí)候
integer(4) :: re_status
type(unionbuff) :: buff
re_status = receive(buff)
select case(buff%itype)
case(typeA) !電文A的類型標(biāo)志
! 按照類型A處理
call process_A(buff%union_data%msg_map_a)
case(typeB) !電文B的類型標(biāo)志
! 按照類型B處理
call process_B(buff%union_data%msg_map_b)
end select
transfer()的實(shí)現(xiàn)
面對(duì)著原本的union與map語句萎馅，實(shí)現(xiàn)的功能不過是對(duì)相同一段內(nèi)存使用不同的方式解釋數(shù)據(jù)。難道說標(biāo)準(zhǔn)的Fortran的真的不支持嗎虹蒋？Fortran語言真的如此不實(shí)用糜芳，而必須使用一些非標(biāo)準(zhǔn)的做法？這太令人憤怒了魄衅，這樣不完善的標(biāo)準(zhǔn)居然沒有人意識(shí)到這個(gè)問題峭竣？!!!
好吧，后來當(dāng)我用transfer實(shí)現(xiàn)了這個(gè)數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換功能的時(shí)候晃虫，還是覺得Fortran還算是一個(gè)高級(jí)語言皆撩，不是那么腦殘。實(shí)現(xiàn)方式首先按照接口定義了統(tǒng)一數(shù)據(jù)結(jié)構(gòu)phbuff哲银，類型a電文數(shù)據(jù)msg_A與類型b電文數(shù)據(jù)msg_B
type :: phbuff
integer(4) :: len
integer(4) :: itype
integer(1) :: data[1024]
end type
type :: msg_A
integer(4) :: len
integer(4) :: itype
type(A) :: foo
end type
type :: msg_B
integer(4) :: len
integer(4) :: itype
type(B) :: bar
end type
那么在接收數(shù)據(jù)時(shí)就可以這么解決
integer(4) :: re_status
type(phbuff) :: buff
type(msg_A) :: dataA
type(msg_B) :: dataB
re_status = receive(buff)
select case(buff%itype)
case(typeA) !電文A的類型標(biāo)志
dataA=transfer(buff, dataA)
! 繼續(xù)按照類型A對(duì)dataA處理
call process_A(dataA%foo)
case(typeB) !電文B的類型標(biāo)志
dataB=transfer(buff,dataB)
! 繼續(xù)按照類型B對(duì)dataB處理
call process_B(dataB%bar)
end select
以上扛吞，便是利用transfer()實(shí)現(xiàn)不同數(shù)據(jù)結(jié)構(gòu)之間數(shù)據(jù)相互轉(zhuǎn)換的用法，可以替代非標(biāo)準(zhǔn)的人union與map
究竟是標(biāo)準(zhǔn)的transfer更好荆责，還是編譯器特別支持的union與map更好滥比？這個(gè)問題針對(duì)不同情況肯定有不同的答案。在我們公司開發(fā)的都是一些小眾的專業(yè)技術(shù)軟件做院，從我的角度代碼可復(fù)用更加重要盲泛。所以在這里我更傾向于標(biāo)準(zhǔn)用法濒持。
（還是用手機(jī)碼的字，如果有手誤的地方通查乒，各位同學(xué)多多包涵弥喉，哈哈哈）
