原创 编写跨平台的软件入门——有关字节对齐

你想过把你的 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 处理器使用是它如此流行的主要原因。

看一个例子：

按照 16 进制的形式来显示上面数据在内存中的存储方式：

我们看到对于数组的第一个元素，高 8 位应该是 0 ，而最终存储的时候是在低 8 位的后面。

而另一方面 PowerPC 和 Sparc 芯片是 big-endian 的，也就是说，最重要的字节存储在较低的地址。对于 CPU 需要额外的电路实现这个功能，但对于今天的处理器技术与缓存控制技术相比较显的微不足道。使用 BIG-ENDIAN 的最大好处是在使用低级调式器时比较容易理解数据的存储，同样对于文件十六进制 DUMP 或网络 Sniffer 显示也是一样的。

对于 BIG-ENDIAN ，上面的例子中内存如下表示：

这里需要注意的是：由于 BIG-ENDIAN 格式的 RAW 数据比较容易调式，如果我们有机会设计一个新的文件格式，那么使用 BIG-ENDIAN 格式，而不是根据 CPU 架构来决定。

下面看几个关于字节序的问题：

1．  Long 型指针和 char 指针之间的转换

看下面这段代码

程序的含义比较简单，主要是从一个指向 long 的指针强制转换为一个指向 char 的指针，这里假设指针指向的是最不重要的字节地址。

在一个 little-endian 处理器上， charVal 是 0 ，而在一个 big-endian 处理器上， charVal 的值是 3 。这样的问题是最难以发现的问题之一。

为了避免这个错误，使用一个临时变量可以解决这个问题，如下：

上面的第二行代码就保证将在任何架构上都将最不重要的字节传递给 charVal ；编译器处理具体的细节。

2．  读写文件和写网络数据

在从文件读数据或写数据到文件的时候以及网络，对于字节顺序的处理一定要小心；一定记住不能将多个字节的数据写到文件或网络上；例如：

这段代码在 little-endian 和 big-endian 机器上执行的结果是不一样的，如果读数据的时候使用如下代码：

如果这两段代码分别位于 little-endian 和 big-endian 机器上，那么最终得到的 val 不是 1 ，而是 0x01000000 。

解决多字节的读写有很多办法，这里提供两种。

方法 1 ：

写的代码

读的代码

3．  运行时检查字节顺序

4．  字节交换对性能的影响

由于字节顺序的问题导致在处理的时候需要进行字节交换或类似 2 中方法 1 的处理，这里称为交换。通常情况下，做字节顺序的交换并不影响，因为交换两个字节或四个字节值只需要很少的 CPU 指令，并且完全可以在寄存器中执行。

但如果有很多数据需要交换，例如：一个 1024*768 位图的图像，在这么大的循环中执行是影响性能的。

另外对于 3 的运行时检查字节序的代码要查看具体的位置。如果仅仅调用一次或几次，不会影响性能，如果对于上面的这个循环中调用，对性能的影响是显著的，这个时候可以使用一个预编译宏来分别处理。例如：

三，             字节填充

另一个写可移植代码的注意点是结构体的字节对齐和填充。通常，在单个平台上，如果需要保存一个结构体到文件，那么是作为一个整体写到文件的，如下：

如果我们已经将数据按照 big-endian 进行了交换，然后直接将整个结构体写到文件中。那么什么样的数据会被写到磁盘上呢？

实际上我们不知道具体写了什么数据，因为我们还不知道这个代码在什么平台上运行；实际上上面的 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 ：

上面这段代码是很普通的 C++ 代码，但这段代码不一定可以在所有的编译器中都能编译通过。主要的原因在于变量 i 的声明。

C++ 标准说：在 for 循环内部声明的变量在 for 结束的时候无效，因此可以连续使用再次在 for 循环中使用该记数器变量。但很不幸的是很多编译器都提供编译选项来让你觉得变量是否在 for 循环以后仍然有效。 VC 中默认编译选项 /Ze 用来指定 for 循环变量的局部性，但并非所有的编译器都是将这个选项作为默认编译参数；所以为了能让你的代码可以在任意平台编译通过，使用 C 风格的会有保证一点；如下：

2.         示例 2 ： int 型变量的使用

Int 型变量是一个奇怪的东西，它在 16 位机器上是 2 个字节，在 32 位机上是 4 个字节；将来可能在 64 位机上是 8 个字节。所以如果你的代码中有对 int 的使用，而你想代码可以在很多平台上运行，那么一定要注意了。看一下下面的情况：

这个代码可能在不同的平台上得到不同的结果。如果这个代码是在 16 位机器上运行，那么得到的结果与 32 位机器上可能不同。

同样在使用 int 型变量写文件和输出到网络时都要小心这个问题。最好的办法是，在这些情况下不要使用 int 型变量； int 型变量仅仅在程序内部使用。

3.         关于 Bit field 的问题

在 C 语法中有 bit field 的语法，可以根据需要来定义一个符号具体占用的 bit 数，例如：

实际上 tagTest 的字节数是 1 个字节，成员 a 占用 4 位， b 和各占用两位。这样的好处是可以针对每个成员赋值而设置指定的位的值，例如：

假如你在 Windows 上是使用 VC 来编译连接上面的程序，不管如何处理，你不会发生任何问题。但现在我们假设将 myTest 放入缓冲区中，然后在 MAC 机器上取出来，那么会发生什么来？看代码：

那么 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://lionwq.spaces.eepw.com.cn/articles/trackback/item/19180