你想過把你的 Windows 上編寫的程序在 Linux 編譯運(yùn)行嗎，以及在 Mac 或其他 OS 上運(yùn)行等等？反過來也一樣？這就需要涉及到跨平臺(tái)編程知識(shí)。這里需要注意的是，平時(shí)很多在一個(gè)平臺(tái)運(yùn)行的程序在跨平臺(tái)的時(shí)候變的不再正確。
Java 并非真的是跨平臺(tái)的開發(fā)環(huán)境，它是運(yùn)行在它自己的平臺(tái)上。這里主要關(guān)注 C 和 C++ 的跨平臺(tái)開發(fā)。
下面主要就幾個(gè)方面來討論跨平臺(tái)編程的注意事項(xiàng)：
1． 字節(jié)序
2． 字節(jié)填充
3． 其他
二， 字節(jié)序
大家都知道計(jì)算機(jī)使用兩種字節(jié)序，一種是 little-endian ，另一種是 big-endian 。這主要是由于當(dāng)前流行的 CPU 之間的差異造成的，基本上是 IBM-PowerPC 使用的大序，而其他 CPU 使用的小序。
這里先來介紹一下 little-endian 和 big-endian 之間的具體差異。
X86 指 令集合使用小序（ little-endian ）字節(jié)順序；這就意味著多個(gè)字節(jié)值的最重要字節(jié)在地址的最低位。小序很早就使用，因?yàn)橛布菀讓?shí)現(xiàn)，但和今天的制造商技術(shù)有點(diǎn)不同；但在第一代 IBM PC 機(jī)的 Vaxen 和 8086 處理器使用是它如此流行的主要原因。
看一個(gè)例子：
| short example[2] = {0x0001,0x0302}; |
按照 16 進(jìn)制的形式來顯示上面數(shù)據(jù)在內(nèi)存中的存儲(chǔ)方式：
我們看到對于數(shù)組的第一個(gè)元素，高 8 位應(yīng)該是 0 ，而最終存儲(chǔ)的時(shí)候是在低 8 位的后面。
而 另一方面 PowerPC 和 Sparc 芯片是 big-endian 的，也就是說，最重要的字節(jié)存儲(chǔ)在較低的地址。對于 CPU 需要額外的電路實(shí)現(xiàn)這個(gè)功能，但對于今天的處理器技術(shù)與緩存控制技術(shù)相比較顯的微不足道。使用 BIG-ENDIAN 的最大好處是在使用低級(jí)調(diào)式器時(shí)比較容易理解數(shù)據(jù)的存儲(chǔ)，同樣對于文件十六進(jìn)制 DUMP 或網(wǎng)絡(luò) Sniffer 顯示也是一樣的。
對于 BIG-ENDIAN ，上面的例子中內(nèi)存如下表示：
這里需要注意的是：由于 BIG-ENDIAN 格式的 RAW 數(shù)據(jù)比較容易調(diào)式，如果我們有機(jī)會(huì)設(shè)計(jì)一個(gè)新的文件格式，那么使用 BIG-ENDIAN 格式，而不是根據(jù) CPU 架構(gòu)來決定。
下面看幾個(gè)關(guān)于字節(jié)序的問題：
1． Long 型指針和 char 指針之間的轉(zhuǎn)換
看下面這段代碼
| unsigned long value = 0x03020100; unsigned long *ptr = &value; unsigned char charVal; charVal = *(unsigned char *)ptr; |
程序的含義比較簡單，主要是從一個(gè)指向 long 的指針強(qiáng)制轉(zhuǎn)換為一個(gè)指向 char 的指針，這里假設(shè)指針指向的是最不重要的字節(jié)地址。
在一個(gè) little-endian 處理器上， charVal 是 0 ，而在一個(gè) big-endian 處理器上， charVal 的值是 3 。這樣的問題是最難以發(fā)現(xiàn)的問題之一。
為了避免這個(gè)錯(cuò)誤，使用一個(gè)臨時(shí)變量可以解決這個(gè)問題，如下：
| unsigned long temp = *ptr; charVal = (unsigned char)temp; |
上面的第二行代碼就保證將在任何架構(gòu)上都將最不重要的字節(jié)傳遞給 charVal ；編譯器處理具體的細(xì)節(jié)。
2． 讀寫文件和寫網(wǎng)絡(luò)數(shù)據(jù)
在從文件讀數(shù)據(jù)或?qū)憯?shù)據(jù)到文件的時(shí)候以及網(wǎng)絡(luò)，對于字節(jié)順序的處理一定要小心；一定記住不能將多個(gè)字節(jié)的數(shù)據(jù)寫到文件或網(wǎng)絡(luò)上；例如：
| long val = 1; int result = write(fileDes,&val,sizeof(val)); |
這段代碼在 little-endian 和 big-endian 機(jī)器上執(zhí)行的結(jié)果是不一樣的，如果讀數(shù)據(jù)的時(shí)候使用如下代碼：
| long val ; int result = read(fileDes,&val,sizeof(long)); |
如果這兩段代碼分別位于 little-endian 和 big-endian 機(jī)器上，那么最終得到的 val 不是 1 ，而是 0x01000000 。
解決多字節(jié)的讀寫有很多辦法，這里提供兩種。
方法 1 ：
寫的代碼
| long val = 1; char buf[4]; buf[0] = 0xff&val; buf[1] = (0xff00&val)>>8; buf[2] = (0xff0000&val)>>16; buf[3] = (0xff000000&val)>>24; int result = write(fileDes,buf,4); |
讀的代碼
| long val; char buf[4]; int result = read(fileDes,buf,4); val = buf[0]|(buf[1]<<8)|(buf[2]<<16)|(buf[3]<<24); |
3． 運(yùn)行時(shí)檢查字節(jié)順序
| bool gIsBigEndian; void InitializeEndianFlag() { Short one = 1; Char *cp = (char *)&one; If(*cp == 0) gIsBigEndian = true; else gIsBigEndian = false; return ; } |
4． 字節(jié)交換對性能的影響
由于字節(jié)順序的問題導(dǎo)致在處理的時(shí)候需要進(jìn)行字節(jié)交換或類似 2 中方法 1 的處理，這里稱為交換。通常情況下，做字節(jié)順序的交換并不影響，因?yàn)榻粨Q兩個(gè)字節(jié)或四個(gè)字節(jié)值只需要很少的 CPU 指令，并且完全可以在寄存器中執(zhí)行。
但如果有很多數(shù)據(jù)需要交換，例如：一個(gè) 1024*768 位圖的圖像，在這么大的循環(huán)中執(zhí)行是影響性能的。
另外對于 3 的運(yùn)行時(shí)檢查字節(jié)序的代碼要查看具體的位置。如果僅僅調(diào)用一次或幾次，不會(huì)影響性能，如果對于上面的這個(gè)循環(huán)中調(diào)用，對性能的影響是顯著的，這個(gè)時(shí)候可以使用一個(gè)預(yù)編譯宏來分別處理。例如：
| #ifdef BIG_ENDIAN//big-endian … #else//little-endian … #endif//BIG_ENDIAN |
三， 字節(jié)填充
另一個(gè)寫可移植代碼的注意點(diǎn)是結(jié)構(gòu)體的字節(jié)對齊和填充。通常，在單個(gè)平臺(tái)上，如果需要保存一個(gè)結(jié)構(gòu)體到文件，那么是作為一個(gè)整體寫到文件的，如下：
| struct myStruct{ char theChar; long theLong; }; struct myStruct foo; foo.the Char = 1; foo.theLong = 2; |
如果我們已經(jīng)將數(shù)據(jù)按照 big-endian 進(jìn)行了交換，然后直接將整個(gè)結(jié)構(gòu)體寫到文件中。那么什么樣的數(shù)據(jù)會(huì)被寫到磁盤上呢？
| int result = write(fileDes, &foo, sizeof(foo)); |
實(shí)際上我們不知道具體寫了什么數(shù)據(jù)，因?yàn)槲覀冞€不知道這個(gè)代碼在什么平臺(tái)上運(yùn)行；實(shí)際上上面的 code 中會(huì)將垃圾數(shù)據(jù)寫到文件里，垃圾數(shù)據(jù)多少由 foo 分配到的內(nèi)存決定的。
一種可能我們認(rèn)為的情況是：
但我們可能得到的這樣的數(shù)據(jù)：
甚至是：
這里到底發(fā)生了什么？ sizeof(foo) 是編譯器和處理器依賴的。
有 些處理器不能從某些位置讀或?qū)懚鄠€(gè)字節(jié)；幾乎所有的都不能從奇數(shù)地址來讀數(shù)據(jù)。通常他們只讀那些是 sizeof （ value ）倍數(shù)的地址；對于四個(gè)字節(jié)只能讀地址是 4 個(gè)字節(jié)的倍數(shù)，對于 2 個(gè)字節(jié)的 short 只能讀兩個(gè)字節(jié)倍數(shù)的地址。如果不遵從這個(gè)字節(jié)對齊的規(guī)律，處理器會(huì)拋出一個(gè)異常并且終止程序，有些系統(tǒng)上會(huì)鎖定機(jī)器（如果發(fā)生在 kernel 中）。
有 時(shí)，讀沒有對齊的數(shù)據(jù)需要花費(fèi)額外的時(shí)間。例如： PowerPC 能夠讀任何偶數(shù)地址，但對于那些不能被 4 整除的地址需要耗費(fèi)額外的總線周期。為了讀一個(gè) long 數(shù)值（ value ）在 2 整除而不是 4 整除的地址，它將讀四個(gè)字節(jié)并包括需要讀的值的上面兩個(gè)字節(jié)，拋棄 2 個(gè)字節(jié)，然后讀另外四個(gè)包含 value 低 2 個(gè)字節(jié)的字節(jié)，同樣拋棄另外兩個(gè)。這與讀 4 個(gè)字節(jié)對齊的地址相比需要多訪問一次緩存。
為了達(dá)到字節(jié)對齊的目的，編譯器會(huì)插入未命名的填充字節(jié)到結(jié)構(gòu)體中。至于插入幾個(gè)字節(jié)是通過編譯器和 OS 或庫內(nèi)存分配器一起決定的。
在 Windows VC 編譯器中，可以使用 #pragma 來指定字節(jié)對齊的方式。
總而言之，在定義結(jié)構(gòu)的時(shí)候要按照字節(jié)邊界對齊來定義，一般按照 4 個(gè)字節(jié)，如果不夠就需要增加填充字段。
另外對于結(jié)構(gòu)體寫文件或輸出到網(wǎng)絡(luò)上，最好的辦法是按照成員來逐個(gè)寫入或發(fā)送，這可以避免將垃圾數(shù)據(jù)存放到文件中或傳輸?shù)骄W(wǎng)絡(luò)上。
四， 其他
下面是幾個(gè)筆者在實(shí)際編寫代碼中發(fā)生過的錯(cuò)誤，這里與大家一道分析一下。
1. 示例 1 ：
| for(int i = 0;i<1000;i++) { …. } ... for(int i = 0;i<1000;i++) { ... } |
上面這段代碼是很普通的 C++ 代碼，但這段代碼不一定可以在所有的編譯器中都能編譯通過。主要的原因在于變量 i 的聲明。
C++ 標(biāo) 準(zhǔn)說：在 for 循環(huán)內(nèi)部聲明的變量在 for 結(jié)束的時(shí)候無效，因此可以連續(xù)使用再次在 for 循環(huán)中使用該記數(shù)器變量。但很不幸的是很多編譯器都提供編譯選項(xiàng)來讓你覺得變量是否在 for 循環(huán)以后仍然有效。 VC 中默認(rèn)編譯選項(xiàng) /Ze 用來指定 for 循環(huán)變量的局部性，但并非所有的編譯器都是將這個(gè)選項(xiàng)作為默認(rèn)編譯參數(shù)；所以為了能讓你的代碼可以在任意平臺(tái)編譯通過，使用 C 風(fēng)格的會(huì)有保證一點(diǎn)；如下：
| int i = 0; for(i = 0;i<1000;i++) { …. } ... for(i = 0;i<1000;i++) { ... } |
2. 示例 2 ： int 型變量的使用
Int 型變量是一個(gè)奇怪的東西，它在 16 位機(jī)器上是 2 個(gè)字節(jié)，在 32 位機(jī)上是 4 個(gè)字節(jié)；將來可能在 64 位機(jī)上是 8 個(gè)字節(jié)。所以如果你的代碼中有對 int 的使用，而你想代碼可以在很多平臺(tái)上運(yùn)行，那么一定要注意了。看一下下面的情況：
| for(int i = 0;i<65540;i++) { …. } |
這個(gè)代碼可能在不同的平臺(tái)上得到不同的結(jié)果。如果這個(gè)代碼是在 16 位機(jī)器上運(yùn)行，那么得到的結(jié)果與 32 位機(jī)器上可能不同。
同樣在使用 int 型變量寫文件和輸出到網(wǎng)絡(luò)時(shí)都要小心這個(gè)問題。最好的辦法是，在這些情況下不要使用 int 型變量； int 型變量僅僅在程序內(nèi)部使用。
3. 關(guān)于 Bit field 的問題
在 C 語法中有 bit field 的語法，可以根據(jù)需要來定義一個(gè)符號(hào)具體占用的 bit 數(shù)，例如：
| typedef struct tagTest
{
char a:4;
char b:2;
char c:2;
}TagTest,*PTagTest; |
實(shí)際上 tagTest 的字節(jié)數(shù)是 1 個(gè)字節(jié)，成員 a 占用 4 位， b 和各占用兩位。這樣的好處是可以針對每個(gè)成員賦值而設(shè)置指定的位的值，例如：
| tagTest myTest;
myTest.a = 10;
myTest.b = 2;
myTest.c = 1; |
假如你在 Windows 上是使用 VC 來編譯連接上面的程序，不管如何處理，你不會(huì)發(fā)生任何問題。但現(xiàn)在我們假設(shè)將 myTest 放入緩沖區(qū)中，然后在 MAC 機(jī)器上取出來，那么會(huì)發(fā)生什么來？看代碼：
| Windows: char buf[10]; buf[0] = myTest; buf[2]=... int result = send(fd,buf,10,..); MAC: char buf[10]; int ret = 0; int result = recv(fd,buf,10,..); PTagTest pTest = (PTagTest)&buf[0]; if(pTest->a == 10) ret = 1; else ret = 0; ... |
那么 ret 的值是什么呢？我們期望是 1 但，結(jié)果不是 1 。如果你通過調(diào)試器來觀察一下 pTest 各成員的值你發(fā)現(xiàn)：
pTest->a = 6; pTest->b =2 ; pTest->c =2;
細(xì) 心的讀者可能發(fā)現(xiàn)這里的問題所在，原因在于不同的編譯器對 bit field 進(jìn)行了不同的處理。在 Windows 平臺(tái)上， c 被放在字節(jié)的最高兩位，而 a 被放在字節(jié)的最低 4 位，在 MAC 上正好相反。但一定要注意，這是編譯器行為，而不是數(shù)據(jù)在傳輸過程中發(fā)生了字節(jié)的位交換。在 Windows 發(fā)送到網(wǎng)絡(luò)的時(shí)候， buf[0] 的內(nèi)容二進(jìn)制表示為：
在 MAC 上 recv 之后， buf[0] 的內(nèi)容仍然與上面的相同。
為了避免這個(gè)問題，請不要在寫文件或網(wǎng)絡(luò)輸出的時(shí)候使用 BIT FILED 語法，如果一定要使用請注意編譯器對位處理的區(qū)別。
n 五 小結(jié)
其 實(shí)實(shí)際工作中，大家認(rèn)為自己的代碼都不需要在多個(gè)平臺(tái)上運(yùn)行，而認(rèn)為跨平臺(tái)編碼與自己無關(guān)；其實(shí)不然，好的編碼習(xí)慣是慢慢養(yǎng)成的，如果大家都知道這些跨平 臺(tái)編碼的細(xì)節(jié)，在開始寫代碼的時(shí)候就開始避免這樣的問題，一旦有一天我們的代碼需要跨平臺(tái)運(yùn)行或一點(diǎn)我們要寫跨平臺(tái)代碼時(shí)，我們就不會(huì)無從下手，而是順其 自然，因?yàn)槲覀円呀?jīng)具備了這樣的習(xí)慣。
當(dāng)然這里的介紹只是一個(gè)開始，跨平臺(tái)編碼涉及的問題還很多，由于筆者經(jīng)驗(yàn)的限制不能一一描述。