一,
为什么要跨平台?
你想过把你的
Windows
上编写的程序在
Linux
编译运行吗,以及在
Mac
或其他
OS
上运行等等?反过来也一样?这就需要涉及到跨平台编程知识。这里需要注意的是,平时很多在一个平台运行的程序在跨平台的时候变的不再正确。
Java
并非真的是跨平台的开发环境,它是运行在它自己的平台上。这里主要关注
C
和
C++
的跨平台开发。
下面主要就几个方面来讨论跨平台编程的注意事项:
1.
字节序
2.
字节填充
3.
其他
二,
字节序
大家都知道计算机使用两种字节序,一种是
little-endian
,另一种是
big-endian
。这主要是由于当前流行的
CPU
之间的差异造成的,基本上是
IBM-PowerPC
使用的大序,而其他
CPU
使用的小序。
这里先来介绍一下
little-endian
和
big-endian
之间的具体差异。
X86
指令集合使用小序(
little-endian
)字节顺序;这就意味着多个字节值的最重要字节在地址的最低位。小序很早就使用,因为硬件容易实现,但和今天的制造商技术有点不同;但在第一代
IBM PC
机的
Vaxen
和
8086
处理器使用是它如此流行的主要原因。
看一个例子:
short example[2] = {0x0001,0x3002};
|
按照
16
进制的形式来显示上面数据在内存中的存储方式:
我们看到对于数组的第一个元素,高
8
位应该是
0
,而最终存储的时候是在低
8
位的后面。
而另一方面
PowerPC
和
Sparc
芯片是
big-endian
的,也就是说,最重要的字节存储在较低的地址。对于
CPU
需要额外的电路实现这个功能,但对于今天的处理器技术与缓存控制技术相比较显的微不足道。使用
BIG-ENDIAN
的最大好处是在使用低级调式器时比较容易理解数据的存储,同样对于文件十六进制
DUMP
或网络
Sniffer
显示也是一样的。
对于
BIG-ENDIAN
,上面的例子中内存如下表示:
这里需要注意的是:由于
BIG-ENDIAN
格式的
RAW
数据比较容易调式,如果我们有机会设计一个新的文件格式,那么使用
BIG-ENDIAN
格式,而不是根据
CPU
架构来决定。
下面看几个关于字节序的问题:
1.
Long
型指针和
char
指针之间的转换
看下面这段代码
unsigned long value = 0x03020100;
unsigned long *ptr = &value;
unsigned char charVal;
charVal = *(unsigned char *)ptr;
|
程序的含义比较简单,主要是从一个指向
long
的指针强制转换为一个指向
char
的指针,这里假设指针指向的是最不重要的字节地址。
在一个
little-endian
处理器上,
charVal
是
0
,而在一个
big-endian
处理器上,
charVal
的值是
3
。这样的问题是最难以发现的问题之一。
为了避免这个错误,使用一个临时变量可以解决这个问题,如下:
unsigned long temp = *ptr;
charVal = (unsigned char)temp;
|
上面的第二行代码就保证将在任何架构上都将最不重要的字节传递给
charVal
;编译器处理具体的细节。
2.
读写文件和写网络数据
在从文件读数据或写数据到文件的时候以及网络,对于字节顺序的处理一定要小心;一定记住不能将多个字节的数据写到文件或网络上;例如:
long val = 1;
int result = write(fileDes,&val,sizeof(val));
|
这段代码在
little-endian
和
big-endian
机器上执行的结果是不一样的,如果读数据的时候使用如下代码:
long val ;
int result = read(fileDes,&val,sizeof(long));
|
如果这两段代码分别位于
little-endian
和
big-endian
机器上,那么最终得到的
val
不是
1
,而是
0x01000000
。
解决多字节的读写有很多办法,这里提供两种。
方法
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.
运行时检查字节顺序
bool gIsBigEndian;
void InitializeEndianFlag()
{
Short one = 1;
Char *cp = (char *)&one;
If(*cp == 0)
gIsBigEndian = true;
else
gIsBigEndian = false;
return ;
}
|
4.
字节交换对性能的影响
由于字节顺序的问题导致在处理的时候需要进行字节交换或类似
2
中方法
1
的处理,这里称为交换。通常情况下,做字节顺序的交换并不影响,因为交换两个字节或四个字节值只需要很少的
CPU
指令,并且完全可以在寄存器中执行。
但如果有很多数据需要交换,例如:一个
1024*768
位图的图像,在这么大的循环中执行是影响性能的。
另外对于
3
的运行时检查字节序的代码要查看具体的位置。如果仅仅调用一次或几次,不会影响性能,如果对于上面的这个循环中调用,对性能的影响是显著的,这个时候可以使用一个预编译宏来分别处理。例如:
#ifdef BIG_ENDIAN//big-endian
…
#else//little-endian
…
#endif//BIG_ENDIAN
|
三,
字节填充
另一个写可移植代码的注意点是结构体的字节对齐和填充。通常,在单个平台上,如果需要保存一个结构体到文件,那么是作为一个整体写到文件的,如下:
struct myStruct{
char theChar;
long theLong;
};
struct myStruct foo;
foo.the Char = 1;
foo.theLong = 2;
|
如果我们已经将数据按照
big-endian
进行了交换,然后直接将整个结构体写到文件中。那么什么样的数据会被写到磁盘上呢?
int result = write(fileDes, &foo, sizeof(foo));
|
实际上我们不知道具体写了什么数据,因为我们还不知道这个代码在什么平台上运行;实际上上面的
code
中会将垃圾数据写到文件里,垃圾数据多少由
foo
分配到的内存决定的。
一种可能我们认为的情况是:
但我们可能得到的这样的数据:
甚至是:
这里到底发生了什么?
sizeof(foo)
是编译器和处理器依赖的。
有些处理器不能从某些位置读或写多个字节;几乎所有的都不能从奇数地址来读数据。通常他们只读那些是
sizeof
(
value
)倍数的地址;对于四个字节只能读地址是
4
个字节的倍数,对于
2
个字节的
short
只能读两个字节倍数的地址。如果不遵从这个字节对齐的规律,处理器会抛出一个异常并且终止程序,有些系统上会锁定机器(如果发生在
kernel
中)。
有时,读没有对齐的数据需要花费额外的时间。例如:
PowerPC
能够读任何偶数地址,但对于那些不能被
4
整除的地址需要耗费额外的总线周期。为了读一个
long
数值(
value
)在
2
整除而不是
4
整除的地址,它将读四个字节并包括需要读的值的上面两个字节,抛弃
2
个字节,然后读另外四个包含
value
低
2
个字节的字节,同样抛弃另外两个。这与读
4
个字节对齐的地址相比需要多访问一次缓存。
为了达到字节对齐的目的,编译器会插入未命名的填充字节到结构体中。至于插入几个字节是通过编译器和
OS
或库内存分配器一起决定的。
在
Windows VC
编译器中,可以使用
#pragma
来指定字节对齐的方式。
总而言之,在定义结构的时候要按照字节边界对齐来定义,一般按照
4
个字节,如果不够就需要增加填充字段。
另外对于结构体写文件或输出到网络上,最好的办法是按照成员来逐个写入或发送,这可以避免将垃圾数据存放到文件中或传输到网络上。
四,
其他
下面是几个笔者在实际编写代码中发生过的错误,这里与大家一道分析一下。
1.
示例
1
:
for(int i = 0;i<1000;i++)
{
….
}
...
for(int i = 0;i<1000;i++)
{
...
}
|
上面这段代码是很普通的
C++
代码,但这段代码不一定可以在所有的编译器中都能编译通过。主要的原因在于变量
i
的声明。
C++
标准说:在
for
循环内部声明的变量在
for
结束的时候无效,因此可以连续使用再次在
for
循环中使用该记数器变量。但很不幸的是很多编译器都提供编译选项来让你觉得变量是否在
for
循环以后仍然有效。
VC
中默认编译选项
/Ze
用来指定
for
循环变量的局部性,但并非所有的编译器都是将这个选项作为默认编译参数;所以为了能让你的代码可以在任意平台编译通过,使用
C
风格的会有保证一点;如下:
int i = 0;
for(i = 0;i<1000;i++)
{
….
}
...
for(i = 0;i<1000;i++)
{
...
}
|
2.
示例
2
:
int
型变量的使用
Int
型变量是一个奇怪的东西,它在
16
位机器上是
2
个字节,在
32
位机上是
4
个字节;将来可能在
64
位机上是
8
个字节。所以如果你的代码中有对
int
的使用,而你想代码可以在很多平台上运行,那么一定要注意了。看一下下面的情况:
for(int i = 0;i<65540;i++)
{
….
}
|
这个代码可能在不同的平台上得到不同的结果。如果这个代码是在
16
位机器上运行,那么得到的结果与
32
位机器上可能不同。
同样在使用
int
型变量写文件和输出到网络时都要小心这个问题。最好的办法是,在这些情况下不要使用
int
型变量;
int
型变量仅仅在程序内部使用。
3.
关于
Bit field
的问题
在
C
语法中有
bit field
的语法,可以根据需要来定义一个符号具体占用的
bit
数,例如:
typedef struct tagTest { char a:4; char b:2; char c:2; }TagTest,*PTagTest;
|
实际上
tagTest
的字节数是
1
个字节,成员
a
占用
4
位,
b
和各占用两位。这样的好处是可以针对每个成员赋值而设置指定的位的值,例如:
tagTest
myTest; myTest.a = 10; myTest.b = 2; myTest.c = 1;
|
假如你在
Windows
上是使用
VC
来编译连接上面的程序,不管如何处理,你不会发生任何问题。但现在我们假设将
myTest
放入缓冲区中,然后在
MAC
机器上取出来,那么会发生什么来?看代码:
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
但,结果不是
1
。如果你通过调试器来观察一下
pTest
各成员的值你发现:
pTest->a = 6; pTest->b =2 ; pTest->c =2;
细心的读者可能发现这里的问题所在,原因在于不同的编译器对
bit field
进行了不同的处理。在
Windows
平台上,
c
被放在字节的最高两位,而
a
被放在字节的最低
4
位,在
MAC
上正好相反。但一定要注意,这是编译器行为,而不是数据在传输过程中发生了字节的位交换。在
Windows
发送到网络的时候,
buf[0]
的内容二进制表示为:
在
MAC
上
recv
之后,
buf[0]
的内容仍然与上面的相同。
为了避免这个问题,请不要在写文件或网络输出的时候使用
BIT FILED
语法,如果一定要使用请注意编译器对位处理的区别。
n
五
小结
其实实际工作中,大家认为自己的代码都不需要在多个平台上运行,而认为跨平台编码与自己无关;其实不然,好的编码习惯是慢慢养成的,如果大家都知道这些跨平台编码的细节,在开始写代码的时候就开始避免这样的问题,一旦有一天我们的代码需要跨平台运行或一点我们要写跨平台代码时,我们就不会无从下手,而是顺其自然,因为我们已经具备了这样的习惯。
当然这里的介绍只是一个开始,跨平台编码涉及的问题还很多,由于笔者经验的限制不能一一描述。
本文参考:
http://www.goingware.com/tips/getting-started/