字节对齐和C/C++函数调用方式学习总结

来源：互联网发布：大雨还在下dj网络歌手编辑：程序博客网时间：2024/04/29 14:02

前言：

《***软件编程规范》中提到：“在定义结构数据类型时，为了提高系统效率，要注意4字节对齐原则……”。本文解释x86上字节对齐的机制，其他架构读者可自行试验。同时，本文对C/C++的函数调用方式进行了讨论。

1．

先看下面的例子：

struct A{

char c1;

int i;

short s;

int j;

}a;

struct B{

int i;

int j;

short s;

char c1;

}b;

结构A没有遵守字节对齐原则（为了区分，我将它叫做对齐声明原则），结构B遵守了。我们来看看在x86上会出现什么结果。先打印出a和b的各个成员的地址。会看到a中，各个成员间的间距是4个字节。b中，i和j，j和s都间距4个字节，但是s和c1间距2个字节。所以：

sizeof(a) = 16

sizeof(b) = 12

为什么会有这样的结果呢？这就是x86上字节对齐的作用。为了加快程序执行的速度，一些体系结构以对齐的方式设计，通常以字长作为对齐边界。对于一些结构体变量，整个结构要对齐在内部成员变量最大的对齐边界，如B，整个结构以4为对齐边界，所以sizeof(b)为12，而不是11。

对于A来讲，虽然声明的时候没有对齐，但是根据打印出的地址来看，编译器已经自动为其对齐了，所以每个成员的间距是4。在x86下，声明A与B唯一的差别，仅在于A多浪费了4个字节内存。（是不是某些特定情况下，B比A执行更快，这个还需要讨论。比如紧挨的两条分别取s和c1的指令）

如果体系结构是不对齐的，A中的成员将会一个挨一个存储，从而sizeof(a)为11。显然对齐更浪费了空间。那么为什么要使用对齐呢？

体系结构的对齐和不对齐，是在时间和空间上的一个权衡。对齐节省了时间。假设一个体系结构的字长为w，那么它同时就假设了在这种体系结构上对宽度为w的数据的处理最频繁也是最重要的。它的设计也是从优先提高对w位数据操作的效率来考虑的。比如说读写时，大多数情况下需要读写w位数据，那么数据通道就会是w位。如果所有的数据访问都以w位对齐，那么访问还可以进一步加快，因为需要传输的地址位减少，寻址可以加快。大多数体系结构都是按照字长来对齐访问数据的。不对齐的时候，有的会出错，比如MIPS上会产生bus error，而x86则会进行多次访问来拼接得到的结果，从而降低执行效率。

有些体系结构是必须要求对齐的，如sparc，MIPS。它们在硬件的设计上就强制性的要求对齐。不是因为它们作不到对齐的访问，而是它们认为这样没有意义。它们追求的是速度。

上面讲了体系结构的对齐。在IA-32上面，sizeof(a)为16，就是对齐的结果。下面我们来看，为什么变量声明的时候也要尽量对齐。

我们看到，结构A的声明并不对齐，但是它的成员地址仍是以4为边界对齐的（成员间距为4）。这是编译器的功劳。因为我所用的编译器gcc，默认是对齐的。而x86可以处理不对齐的数据访问，所以这样声明程序并不会出错。但是对于其他结构，只能访问对齐的数据，而编译器又不小心设置了不对齐的选项，则代码就不能执行了。如果按照B的方式声明，则不管编译器是否设置了对齐选项，都能够正确的访问数据。

目前的开发普遍比较重视性能，所以对齐的问题，有三种不同的处理方法：

1）采用B的方式声明

2）对于逻辑上相关的成员变量希望放在靠近的位置，就写成A的方式。有一种做法是显式的插入reserved成员：

struct A{

char c1;

char reserved1[3];

int i;

short s;

char reserved2[2];

int j;

}a;

3）随便怎么写，一切交给编译器自动对齐。

代码中关于对齐的隐患，很多是隐式的。比如在强制类型转换的时候。下面举个例子：

unsigned int ui_1=0x12345678;

unsigned char *p=NULL;

unsigned short *us_1=NULL;

p=&ui_1;

*p=0x00;

us_1=(unsigned short *)(p+1);

*us_1=0x0000;

最后两句代码，从奇数边界去访问unsigned short型变量，显然不符合对齐的规定。在x86上，类似的操作只会影响效率，但是在MIPS或者sparc上，可能就是一个bus error（我没有试）。

有些人喜欢通过移动指针来操作结构中的成员（比如在linux操作struct sk_buff的成员），但是我们看到，A中(&c1+1) 决不等于&i。不过B中(&s+2)就是 &c1了。所以，我们清楚了结构中成员的存放位置，才能编写无错的代码。同时切记，不管对于结构，数组，或者普通的变量，在作强制类型转换时一定要多看看：）不过为了不那么累，还是遵守声明对齐原则吧！（这个原则是说变量尽量声明在它的对齐边界上，而且在节省空间的基础上）

2．C/C++函数调用方式

我们当然早就知道，C/C++中的函数调用，都是以值传递的方式，而不是参数传递。那么，值传递是如何实现的呢？

函数调用前的典型汇编码如下：

push %eax

call 0x401394 <test__Fc>

add $0x10,%esp

首先，入栈的是实参的地址。由于被调函数都是对地址进行操作，所以就能够理解值传递的原理和参数是引用时的情况了。

Call ***，是要调用函数了，后面的地址，就是函数的入口地址。Call指令等价于：

PUSH IP

JMP ***

首先把当前的执行地址IP压栈，然后跳转到函数执行。

执行完后，被调函数要返回，就要执行RET指令。RET等价于POP IP，恢复CALL之前的执行地址。所以一旦使用CALL指令，堆栈指针SP就会自动减2，因为IP的值进栈了。

函数的参数进栈的顺序是从右到左，这是C与其它语言如pascal的不同之处。函数调用都以以下语句开始：

push %ebp

mov %esp,%ebp

首先保存BP的值，然后将当前的堆栈指针传递给BP。那么现在BP+2就是IP的值（16位register的情况），BP+4放第一个参数的值，BP+6放第二个参数……。函数在结束前，要执行POP BP。

C/C++语言默认的函数调用方式，都是由主调用函数进行参数压栈并且恢复堆栈，实参的压栈顺序是从右到左，最后由主调函数进行堆栈恢复。由于主调用函数管理堆栈，所以可以实现变参函数。

对于WINAPI和CALLBACK函数，在主调用函数中负责压栈，在被调用函数中负责弹出堆栈中的参数，并且负责恢复堆栈。因此不能实现变参函数。

（哪位对编译原理和编译器比较了解的，可以将这个部分写完善，谢谢。可以加入编译时的处理。不然只有等偶继续学习了）字节对齐或内存对齐

转载出处：http://www.blogbus.com/blogbus/blog/archive.php?id=1807

Alignment, Pack and Bit Field . . .

2）关于字节对齐Alignment 的问题现在写出来与大家分享与讨论欢迎指正。

1. 为什么要对齐?

以32位的CPU为例(16 64位同它),一次可以对一个32位的数进行运算,它的数据总线的宽度是32位,它从内存中一次可以存取的最大数为32位,这个数叫CPU的字word 长。

在进行硬件设计时将存储体组织成32位宽，如每个存储体的宽度是8位可用四块存储体与CPU的32位数据总线相连，这也是为什么以前的 386/486计算机插SIMM30内存条(8位)时必须同时插四条的原因。

请参见下图：

1 8 16 24 32

-------- ------- ------- --------

-------- ------- ------- --------

-------- ------- ------- --------

-------- ------- ------- --------

| ....

当一个long型数，(如图中long1 )在内存中的位置正好与内存的字边界对齐时,CPU存取这个数只需访问一次内存,而当一个long型数(如图中long2 ),在内存中的位置跨越字边界时,CPU存取这个数就需多次访问内存,如 i960cx访问这样的数需读内存三次一个BYTE ,一个short ,一个BYTE ,由CPU的微代码执行,对软件透明.所以在对齐方式下CPU的运行效率明显快多了这就是要对齐的原因.

一般在编译器生成代码时,都可以根据各种CPU类型将变量进行对齐,包括结构struct 中的变量,变量与变量之间的空间叫padding.有时为了对齐在一个结构的最后也会填入padding ,通常叫tail padding .但在实际的应用中我们确实有不对齐的要求,如在编通讯程序时帧的结构就不能对齐,否则会带来错误及麻烦,所以各编译器都提供了不对齐的选项.但由于这是ANSI C中未规定的内容所以各厂家的实现都不一样.

下面是我们常用编译器的实现:

2. 一般编译器实现对齐的方法

由于各厂家的实现不一样,这里涉及的内容只使用于Visual C++ 4.x ,Borland C++ 5.0 3.1及pRism x86 1.8.7 (C languange) .其他厂家可能略有不同.

每种基本数据类型都有它的自然对齐方式Natural Alignment, Align的值与该数据类型的大小相等见下表

Data Type sizeof Natural Align

(signed/unsigned)

char 1 1

short 2 2

long 4 4

同时用户还可以指定一个Align值,使用编译开关或使用#pragma .

当用户指定一个Align值 n 或编译器的缺省时,每种数据类型的实际当前Align值定义如下:

Actual Align = min ( n, Natual Align ) //公式 1

如当用户指定Align值为 2 时,char 的实际Align值仍为1 ,short及long的实际Align值为 2 .

当用户指定Align值为 1 时,所有类型的实际Align值都为 1.

复杂数据类型Complex or Aggregate type,包括 array, struct 及union 的对齐值定义如下:

struct 结构的Align值等于该结构所有成员的 Actual Align 值中最大的一个Align 值,注意成员的Align值是它的实际Align值

array 数组的Align值等于该数组成员的 Actual Align 值.

union 联合的Align值等于该联合最大成员的 Actual Align 值.

同时当用户指定一个Align值时上面的公式 1 同样起作用,只不过Natural Align应理解为当前的Actual Align.

那么编译器是如何根据一个类型的Align值来分配存储空间主要是在结构中的空间的呢?

有如下两个规律

1. 一个结构成员的offset等于该成员Actual Align值的整数倍,如果凑不成整数倍就在其前加padding.

2. 一个结构的大小等于该结构Actual Align值的整数倍,如果凑不成整数倍就在其后加padding ,tail padding

一个结构的大小在其定义时就已确定不会因为其Actual Align值的改变而改变.

例如有如下两个结构定义

#pragma pack(8) // 指定Align为 8

struct STest1

{

char ch1;

long lo1;

char ch2;

} test1;

#pragma pack()

现在 Align of STest1 = 4 , sizeof STest1 = 12 ( 4 * 3 )

test1在内存中的排列如下 FF 为 padding

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 FF FF FF 01 01 01 01 01 FF FF FF

ch1 -- lo1 -- ch2

#pragma pack(2) //指定Align为 2

struct STest2

{

char ch3;

STest1 test;

} test2;

#pragma pack()

现在 Align of STest1 = 2, Align of STest2 = 2 ,sizeof STest2 = 14 ( 7 * 2 )

test2在内存中的排列如下

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

02 FF 01 FF FF FF 01 01 01 01 01 FF FF FF

ch3 ch1 -- lo1 -- ch2

从以上可以看出用户可以在任何需要的地方定义不同的align值

3. 不同编译器实现用户指定align 值的方法:

因为是 ANSI C中未规定的内容，所以各厂家的方法都不一样。一般都提供命令行选项及使用#pragma。

命令行选项对所有被编译的文件都起作用#pragma则是ANSI C特别为实现不同的编译器及平台特性而规定的预处理器指令Preprocessor 下面主要讲一下#pragma的实现:

Visual C++ VC使用 #pragma pack( [n] ) ,其中 n 可以是 1, 2, 4, 8, 16, 编译器在遇到一个#pragma pack(n)后就将 n当作当前的用户指定align值直到另一个#pragma pack(n) 。当遇到一个不带 n 的 pack时就恢复以前使用的align值。

Borland C++ BC使用 #pragma option -an ，在 BC 5.0 的Online Help中没有发现对#pragma pack的支持但发现在其系统头文件中使用的都是#pragma pack。

pRism x86 使用 #pragma pack( [n] ) ,但奇怪的是 C 文件与 C++文件生成的代码不一样，有待进一步研究。

gcc960 使用 #pragma pack n 及 #pragma align n 。两个开关的意义不一样，并且相互作用比较复杂。但同时使用 #pragma pack 1 及#pragma align 1 可以实现与Visual C++中 #pragma pack(1) 一样的功能。

其他编译器的方法各不相同，可参见手册。如果要使用不同的编译器编译软件时，就要针对不同的编译器使用不同的预处理器指令。

4. 使用 #pragma pack 或其他开关需注意的问题

1. 为了保证执行速度尽量不使用#pragma pack

2. 不同的编译器生成的代码极有可能不同一定要查看相应手册并做实验

3.需要加pack的地方一定要在定义结构的头文件中加，不要依赖命令行选项。因为如果很多人使用该头文件，并不是每个人都知道应该pack 。特别是为别人开发库文件时，如果一个库函数使用了struct作为其参数，当调用者与库文件开发者使用不同的pack时，就会造成错误，而且该类错误很不好查。在VC及BC提供的头文件中除了能正好对齐在四字节上的结构外都加了pack ，否则我们编的Windows程序哪一个也不会正常运行。

4. 在 #pragma pack(n)后一定不要include其他头文件，若包含的头文件中改变了align值将产生非预期结果。

VC中提供了一种安全使用pack的方法

#pragma pack( [ push | pop ], n )

#pragma pack( push, n)

将当前的align值压入编译器的一个内部堆栈并使用，n作为当前的align值，而#pragma pack(pop)则将内部堆栈中的栈顶值作为当前的align值，这样就保证了嵌套pack时的正确。

5.不要多人同时定义一个数据结构。在多人合作开发一个软件模块时，为了保持自己的编程风格，每个人都要对同一结构定义一份符合自己风格的数据类型，当两个人之间需要传递该数据结构时，如果两个人的 pack值不一样就会产生错误，该类错误也很难查，所以为了安全起见我们还是舍弃一些自己的风格吧。

5. 关于位域 Bit Field

在 ANSI C 中规定位域的类型只能为 signed/unsigned int ，但各厂家都对其进行了扩展类型可以是 char, short, long等但其最大长度不能超过int的长度，即32位平台时为32位，16位平台时为16位。位域存储空间的分配也与各编译器的实现有关，而且与Little Endian(x86,i960),BigEndian(680x0,PowerPc)有关。所以在定义位域时要对不同的编译器进行不同的支持，如在VC中规定如果两个连续位域的类型不一样或位域的长度为零，编译器将进行对齐。在VC中是这样，其他编译器就可能不是这样。这属于各厂家不同的实现问题。ANSI

C 中没有进行规定所以如果涉及到位域问题一定要查看手册。

6. 附例

以下结果均在VC++4.x ，BC++5.0,3.1 pRism x86 1.8.7(C Language)进行过验证。其中因为BC++ 3.1 是16位的所以只有pack(1),pack(2)有效。

例中定义了如下几个结构

typedef struct tagSLong

{

char chMem1;

char chMem2;

char chMem3;

unsigned short wMem4;

unsigned long dwMem5;

unsigned short wMem6;

char chMem7;

}SLong;

typedef struct tagSShort

{

char chMem1;

unsigned short wMem2;

char chMem3;

}SShort;

typedef union tagun

{

char uChar;

unsigned short uWord;

}un;

typedef struct tagComplex

{

char chItem1;

SLong struItem2;

unsigned long dwItem3;

char chItem4;

un unItem5;

}Complex;

测试时对每个结构的成员按 1 2 3 ... 依次进行赋值FF 为Padding

下面列出了每个结构的size Align的大小及其空间分配

1. Now the Align(Pack) size is 8

sizeof(SLong) = 16 Alignment of (SLong) = 4

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF

sizeof(SShort) = 6 Alignment of (SShort) = 2

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 FF 02 00 03 FF

sizeof(Complex) = 28 Alignment of (Complex) = 4

[Notice the alignment of (SLong) = 4 and (un)=2 ]

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 FF FF FF 01 02 03 FF 04 00 FF FF 05 00 00 00

06 00 07 FF 08 00 00 00 09 FF 0A 00

sizeof(SLong[2]) = 32 Alignment of (SLong[2]) = 4

[Notice the alignment of (SLong) = 4 ]

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF

sizeof(un) = 2 Alignment of (un) = 2

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

02 00

2. Now the Align(Pack) size is 4

sizeof(SLong) = 16 Alignment of (SLong) = 4

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF

sizeof(SShort) = 6 Alignment of (SShort) = 2

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 FF 02 00 03 FF

sizeof(Complex) = 28 Alignment of (Complex) = 4

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 FF FF FF 01 02 03 FF 04 00 FF FF 05 00 00 00

06 00 07 FF 08 00 00 00 09 FF 0A 00

sizeof(SLong[2]) = 32 Alignment of (SLong[2]) = 4

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF

sizeof(un) = 2 Alignment of (un) = 2

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

02 00

3. Now the Align(Pack) size is 2

sizeof(SLong) = 14 Alignment of (SLong) = 2

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 02 03 FF 04 00 05 00 00 00 06 00 07 FF

sizeof(SShort) = 6 Alignment of (SShort) = 2

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 FF 02 00 03 FF

sizeof(Complex) = 24 Alignment of (Complex) = 2

[Notice the alignment of (SLong) = 2 and (un) = 2

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 FF 01 02 03 FF 04 00 05 00 00 00 06 00 07 FF

08 00 00 00 09 FF 0A 00

sizeof(SLong[2]) = 28 Alignment of (SLong[2]) = 2

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 02 03 FF 04 00 05 00 00 00 06 00 07 FF 01 02

03 FF 04 00 05 00 00 00 06 00 07 FF

sizeof(un) = 2 Alignment of (un) = 2

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

02 00

4. Now the Align(Pack) size is 1

sizeof(SLong) = 12 Alignment of (SLong) = 1

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 02 03 04 00 05 00 00 00 06 00 07

sizeof(SShort) = 4 Alignment of (SShort) = 1

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 02 00 03

sizeof(Complex) = 20 Alignment of (Complex) = 1

[Notice the alignment of (SLong) = 1 and (un) = 1]

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 01 02 03 04 00 05 00 00 00 06 00 07 08 00 00

00 09 0A 00

sizeof(SLong[2]) = 24 Alignment of (SLong[2]) = 1

[Notice the alignment of (SLong) = 1 ]

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

01 02 03 04 00 05 00 00 00 06 00 07 01 02 03 04

00 05 00 00 00 06 00 07

sizeof(un) = 2 Alignment of (un) = 1

00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --

02 00

关于pack 使用的几点建议及需注意的问题

0.由于各种编译器对pack的实现各不相同建议定义几个头文件(参照microsoft的做法)

poppack.h, pshpack1.h, pshpack2.h ...

其中poppack.h用于恢复编译器的缺省pack值其大略定义如下

#if _HA_WIN32 //for Visual C++

#pragma pack()

#elif _HA_GNU //for gcc960

#pragma pack

#pragma align 0

#elif ... for any more

pshpack1(n).h用于指定编译器的pack值为 n , 其大略定义如下

#if _HA_WIN32 //for Visual C++

#pragma pack(1)//n

#elif _HA_GNU //for gcc960

#pragma pack 1//n

#pragma align 1//n

#elif ... //for any more

使用时在需要pack的地方加上 #include "pshpack1.h" ,

在需要恢复pack的地方加上 #include "poppack.h" .

使用这种头文件的方式有如下几点好处:

(1). 在需要pack的头文件中不需要再对不同的编译器做处理，使得该头文件比较整洁.

(2). 便于维护.当需要增加对其他编译器的支持或对现有pack指令进行修改时,只需修改poppack.h等几个头文件.

1. 为了保证执行速度在没有必要的地方不要使用#pragma pack 不要只为了节省空间而使用BYTE等类型,其实数据的空间是减少了但代码的空间却变大了,如本来只需一条指令的地方可能需三四条指令,既影响了执行速度又增加了空间，得不偿失。如果必须使用BYTE等类型，尽可能将其在结构中排成自然对齐。

2.不同的编译器生成的代码极有可能不同，一定要查看相应手册并做实验。

如对于如下结构定义

struct SLanDest

{

WORD wTag;

MACADDR addr;

};

该结构在VC下是不加padding的但在pRism下就加了padding

3.需要加pack的地方一定要在定义结构的头文件中加，不要依赖命令行选项。因为如果很多人使用该头文件，并不是每个人都知道应该pack 特别是为别人开发库文件时如果一个库函数使用了struct作为其参数，当调用者与库文件开发者使用不同的pack时，就会造成错误，而且该类错误很不好查。在VC及BC提供的头文件中除了能正好对齐在四字节上的结构外都加了pack，否则我们编的Windows程序哪一个也不会正常运行。

4. 在 #include "pshpack1.h"后一定不要include其他头文件，若包含的头文件中改变了align值，如包含了#include "poppack.h" 将产生非预期结果。

5.不要多人同时定义一个数据结构，在多人合作开发一个软件模块时，为了保持自己的编程风格，每个人都要对同一结构定义一份符合自己风格的数据类型。当两个人之间需要传递该数据结构时如果两个人的 pack值不一样就会产生错误，该类错误也很难查。所以为了安全起见我们还是舍弃一些自己的风格吧。

6. 何时需要加pack?

在编写通信协议时通信协议的帧结构对于所有跨CPU的协议都应理解为通信协议。如邮箱通信主机与主机通过通信线路进行通信等编写硬件驱动程序时，寄存器的结构这两个地方都需要加pack1 即使看起来本来就自然对齐的也要加pack 以免不同的编译器生成的代码不一样。如 2.中的例子对于运行时只与一个CPU有关的结构为了提高执行速度请不要加pack。

3）VC中字节对齐问题

1、 sizeof应用在结构上的情况

请看下面的结构：

struct MyStruct

{

double dda1;

char dda;

int type

};

对结构MyStruct采用sizeof会出现什么结果呢？sizeof(MyStruct)为多少呢？也许你会这样求：

sizeof(MyStruct)=sizeof(double)+sizeof(char)+sizeof(int)=13

但是当在VC中测试上面结构的大小时，你会发现sizeof(MyStruct)为16。你知道为什么在VC中会得出这样一个结果吗？

其实，这是VC对变量存储的一个特殊处理。为了提高CPU的存储速度，VC对一些变量的起始地址做了“对齐”处理。在默认情况下，VC规定各成员变量存放的起始地址相对于结构的起始地址的偏移量必须为该变量的类型所占用的字节数的倍数。下面列出常用类型的对齐方式(vc6.0,32位系统)。

类型

对齐方式（变量存放的起始地址相对于结构的起始地址的偏移量）

Char

偏移量必须为sizeof(char)即1的倍数

int

偏移量必须为sizeof(int)即4的倍数

float

偏移量必须为sizeof(float)即4的倍数

double

偏移量必须为sizeof(double)即8的倍数

Short

偏移量必须为sizeof(short)即2的倍数

各成员变量在存放的时候根据在结构中出现的顺序依次申请空间，同时按照上面的对齐方式调整位置，空缺的字节VC会自动填充。同时VC为了确保结构的大小为结构的字节边界数（即该结构中占用最大空间的类型所占用的字节数）的倍数，所以在为最后一个成员变量申请空间后，还会根据需要自动填充空缺的字节。

下面用前面的例子来说明VC到底怎么样来存放结构的。

struct MyStruct

{

double dda1;

char dda;

int type

}；

为上面的结构分配空间的时候，VC根据成员变量出现的顺序和对齐方式，先为第一个成员dda1分配空间，其起始地址跟结构的起始地址相同（刚好偏移量0刚好为sizeof(double)的倍数），该成员变量占用sizeof(double)=8个字节；接下来为第二个成员dda分配空间，这时下一个可以分配的地址对于结构的起始地址的偏移量为8，是sizeof(char)的倍数，所以把dda存放在偏移量为8的地方满足对齐方式，该成员变量占用 sizeof(char)=1个字节；接下来为第三个成员type分配空间，这时下一个可以分配的地址对于结构的起始地址的偏移量为9，不是sizeof (int)=4的倍数，为了满足对齐方式对偏移量的约束问题，VC自动填充3个字节（这三个字节没有放什么东西），这时下一个可以分配的地址对于结构的起始地址的偏移量为12，刚好是sizeof(int)=4的倍数，所以把type存放在偏移量为12的地方，该成员变量占用sizeof(int)=4个字节；这时整个结构的成员变量已经都分配了空间，总的占用的空间大小为：8+1+3+4=16，刚好为结构的字节边界数（即结构中占用最大空间的类型所占用的字节数sizeof(double)=8）的倍数，所以没有空缺的字节需要填充。所以整个结构的大小为：sizeof(MyStruct)=8+1+ 3+4=16，其中有3个字节是VC自动填充的，没有放任何有意义的东西。

下面再举个例子，交换一下上面的MyStruct的成员变量的位置，使它变成下面的情况：

struct MyStruct

{

char dda;

double dda1;

int type

}；

这个结构占用的空间为多大呢？在VC6.0环境下，可以得到sizeof(MyStruc)为24。结合上面提到的分配空间的一些原则，分析下VC怎么样为上面的结构分配空间的。（简单说明）

struct MyStruct

{

char dda;//偏移量为0，满足对齐方式，dda占用1个字节；

double dda1;//下一个可用的地址的偏移量为1，不是sizeof(double)=8

//的倍数，需要补足7个字节才能使偏移量变为8（满足对齐

//方式），因此VC自动填充7个字节，dda1存放在偏移量为8

//的地址上，它占用8个字节。

int type；//下一个可用的地址的偏移量为16，是sizeof(int)=4的倍

//数，满足int的对齐方式，所以不需要VC自动填充，type存

//放在偏移量为16的地址上，它占用4个字节。

}；//所有成员变量都分配了空间，空间总的大小为1+7+8+4=20，不是结构

//的节边界数（即结构中占用最大空间的类型所占用的字节数sizeof

//(double)=8）的倍数，所以需要填充4个字节，以满足结构的大小为

//sizeof(double)=8的倍数。

所以该结构总的大小为：sizeof(MyStruc)为1+7+8+4+4=24。其中总的有7+4=11个字节是VC自动填充的，没有放任何有意义的东西。

VC对结构的存储的特殊处理确实提高CPU存储变量的速度，但是有时候也带来了一些麻烦，我们也屏蔽掉变量默认的对齐方式，自己可以设定变量的对齐方式。

VC 中提供了#pragma pack(n)来设定变量以n字节对齐方式。n字节对齐就是说变量存放的起始地址的偏移量有两种情况：第一、如果n大于等于该变量所占用的字节数，那么偏移量必须满足默认的对齐方式，第二、如果n小于该变量的类型所占用的字节数，那么偏移量为n的倍数，不用满足默认的对齐方式。结构的总大小也有个约束条件，分下面两种情况：如果n大于所有成员变量类型所占用的字节数，那么结构的总大小必须为占用空间最大的变量占用的空间数的倍数；

否则必须为n的倍数。下面举例说明其用法。

#pragma pack(push) //保存对齐状态

#pragma pack(4)//设定为4字节对齐

struct test

{

char m1;

double m4;

int m3;

};

#pragma pack(pop)//恢复对齐状态

以上结构的大小为16，下面分析其存储情况，首先为m1分配空间，其偏移量为0，满足我们自己设定的对齐方式（4字节对齐），m1占用1个字节。接着开始为 m4分配空间，这时其偏移量为1，需要补足3个字节，这样使偏移量满足为n=4的倍数（因为sizeof(double)大于n）,m4占用8个字节。接着为m3分配空间，这时其偏移量为12，满足为4的倍数，m3占用4个字节。这时已经为所有成员变量分配了空间，共分配了16个字节，满足为n的倍数。如果把上面的#pragma pack(4)改为#pragma pack(16)，那么我们可以得到结构的大小为24。（请读者自己分析）

2、 sizeof用法总结

在VC中，sizeof有着许多的用法，而且很容易引起一些错误。下面根据sizeof后面的参数对sizeof的用法做个总结。

A．参数为数据类型或者为一般变量。例如sizeof(int),sizeof(long)等等。这种情况要注意的是不同系统系统或者不同编译器得到的结果可能是不同的。例如int类型在16位系统中占2个字节，在32位系统中占4个字节。

B．参数为数组或指针。下面举例说明.

int a[50]; //sizeof(a)=4*50=200; 求数组所占的空间大小

int *a=new int[50];// sizeof(a)=4; a为一个指针，sizeof(a)是求指针

//的大小,在32位系统中，当然是占4个字节。

C．参数为结构或类。Sizeof应用在类和结构的处理情况是相同的。但有两点需要注意，第一、结构或者类中的静态成员不对结构或者类的大小产生影响，因为静态变量的存储位置与结构或者类的实例地址无关。

第二、没有成员变量的结构或类的大小为1，因为必须保证结构或类的每一

个实例在内存中都有唯一的地址。

下面举例说明，

Class Test{int a;static double c};//sizeof(Test)=4.

Test *s;//sizeof(s)=4,s为一个指针。

Class test1{ };//sizeof(test1)=1;

D．参数为其他。下面举例说明。

int func(char s[5]);

{

cout<

//数的参数在传递的时候系统处理为一个指针，所

//以sizeof(s)实际上为求指针的大小。

return 1;

}

sizeof(func(“1234”))=4//因为func的返回类型为int，所以相当于

//求sizeof(int).

以上为sizeof的基本用法，在实际的使用中要注意分析VC的分配变量的分配策略，这样的话可以避免一些错误

gcc 的字节对齐扩展

在阅读ffmpeg代码时经常看到类似下面的语句:

#pragma pack(n)

#pragma pack()

和

__attribute((aligned (8)))

__attribute__ ((packed));

例如:

# ifdef __GNUC__

static inline uint32_t unaligned32(const void *v)

{

struct Unaligned

{

uint32_t i;

} __attribute__((packed));

return ((const struct Unaligned *) v)->i;

}

struct FieldTest

{

int a;

char b;

char c;

}__attribute__((packed)) ft;

// 取消编译器优化对齐，取实际长度

//----------------------------------------------------

这两种方式是gcc的c扩展，用来对齐的，包括栈对齐，变量地址对齐,内存分配对齐和结构体对齐方式.

Note:在设置新的#pragma pack(n)之前,应该先取消以前的对齐,也就是说要调用一下#pragma pack().

#pragma pack(n)

n的取值可以为1、2、4、8,在编译过程中按照n个字结对齐

#pragma pack()

取消对齐，按照编译器的优化对齐方式对齐

__attribute__ ((packed));

是说取消结构在编译过程中的优化对齐。

__attribute__ ((aligned (n)));

让所作用的成员对齐在n字节自然边界上,如果结构中有成员的长度大于n，则按照机器字长来对齐

gcc手册中说了不建议使用 #pragma,而且#pragma最多只能支持8字节的对齐.

由于不同编译器可能对对齐的实现有区别，在不同编译器编译的程序间进行数据传递就有可能要用到这些东西了.

struct abc {

u32 sid;

u8 p;

union {

int digest[4];

char ctldta[10];

} data;

char dummy[0] __attribute__ ((aligned (64)));

} __attribute__ ((packed));

//__attribute__ ((packed)); 是说取消结构在编译过程中的优化对齐。

//__attribute__ ((aligned (64))); 是说让dummy成员对齐在64-bit自然边界上。

#include <iostream.h>

struct FieldTest

{

int a;

char b;

char c;

} __attribute__((aligned(16))) ft; //Aligned by 128 bit

int main(int argc,char** argv)

{

cout<<"the size of FieldTest is "<<sizeof(ft)<<endl;

return 0;

}

//---------------------------------------------------------

g++ packed_test.cpp -o test.exe -Wno-deprecated

./test.exe

the size of FieldTest is 16

人为对齐就是保证每组数据都是4字节的。

例如：

{

char s1[3] ;

long l ;

char s2 ;

}

应改为

{

char s1[3] ;

char s2 ;

long l ;

}

同理，

{

short a ;

long l ;

short b ;

}

应改为

{

short a ;

short b ;

long l ;

}

就是保证每个数据的起始位置符合4字节对齐要求。

若是有奇数个short, 如：

{

short s1;

short s2;

short s3;

long l ;

}

那么要想对齐，就得手工补足：

{

short s1;

short s2;

short s3;

short temp ;

long l ;

}

这样就不用编译器帮你对齐了。它的最大好处其实是不论1，2，4字节对齐，

编译器生成的结构都是一样的。这在通信和文件保存方面有莫大的好处。

char也一样，全应补足为4字节。

更改C编译器的缺省字节对齐方式

在缺省情况下，C编译器为每一个变量或是数据单元按其自然对界条件分配空间。一般地，可以通过下面的方法来改变缺省的对界条件：

　　• 使用伪指令#pragma pack (n)，C编译器将按照n个字节对齐。

• 使用伪指令#pragma pack ()，取消自定义字节对齐方式。

另外，还有如下的一种方式：

• __attribute((aligned (n)))，让所作用的结构成员对齐在n字节自然边界上。如果结构中有成员的长度大于n，则按照最大成员的长度来对齐。

• __attribute__ ((packed))，取消结构在编译过程中的优化对齐，按照实际占用字节数进行对齐。

以上的n = 1, 2, 4, 8, 16... 第一种方式较为常见。

应用实例

　　在网络协议编程中，经常会处理不同协议的数据报文。一种方法是通过指针偏移的方法来得到各种信息，但这样做不仅编程复杂，而且一旦协议有变化，程序修改起来也比较麻烦。在了解了编译器对结构空间的分配原则之后，我们完全可以利用这一特性定义自己的协议结构，通过访问结构的成员来获取各种信息。这样做，不仅简化了编程，而且即使协议发生变化，我们也只需修改协议结构的定义即可，其它程序无需修改，省时省力。下面以TCP协议首部为例，说明如何定义协议结构。其协议结构定义如下：

#pragma pack(1) // 按照1字节方式进行对齐

struct TCPHEADER

{

short SrcPort; // 16位源端口号

short DstPort; // 16位目的端口号

int SerialNo; // 32位序列号

int AckNo; // 32位确认号

unsigned char HaderLen : 4; // 4位首部长度

unsigned char Reserved1 : 4; // 保留6位中的4位

unsigned char Reserved2 : 2; // 保留6位中的2位

unsigned char URG : 1;

unsigned char ACK : 1;

unsigned char PSH : 1;

unsigned char RST : 1;

unsigned char SYN : 1;

unsigned char FIN : 1;

short WindowSize; // 16位窗口大小

short TcpChkSum; // 16位TCP检验和

short UrgentPointer; // 16位紧急指针

};

#pragma pack() // 取消1字节对齐方式

4）C++ 代码优化

谈到优化，很多人都会直接想到汇编。难道优化只能在汇编层次吗？当然不是，C++层次一样可以作代码优化，其中有些常常是意想不到的。在C++层次进行优化，比在汇编层次优化具有更好的移植性，应该是优化中的首选做法。

　　确定浮点型变量和表达式是 float 型

　　为了让编译器产生更好的代码(比如说产生3DNow! 或SSE指令的代码)，必须确定浮点型变量和表达式是 float 型的。要特别注意的是，以 "；F"；或 "；f"；为后缀（比如：3.14f）的浮点常量才是 float 型，否则默认是 double 型。为了避免 float 型参数自动转化为 double，请在函数声明时使用 float。

　　使用32位的数据类型

　　编译器有很多种，但它们都包含的典型的32位类型是：int，signed，signed int，unsigned，unsigned int，long，signed long，long int，signed long int，unsigned long，unsigned long int。尽量使用32位的数据类型，因为它们比16位的数据甚至8位的数据更有效率。

　　明智使用有符号整型变量

　　在很多情况下，你需要考虑整型变量是有符号还是无符号类型的。比如，保存一个人的体重数据时不可能出现负数，所以不需要使用有符号类型。但是，如果是要保存温度数据，就必须使用到有符号的变量。

　　在许多地方，考虑是否使用有符号的变量是必要的。在一些情况下，有符号的运算比较快；但在一些情况下却相反。

　　比如：整型到浮点转化时，使用大于16位的有符号整型比较快。因为x86构架中提供了从有符号整型转化到浮点型的指令，但没有提供从无符号整型转化到浮点的指令。看看编译器产生的汇编代码：

　　不好的代码：

编译前编译后

double x； mov [foo + 4], 0

unsigned int i； mov eax, i

x = i； mov [foo], eax

flid qword ptr [foo]

fstp qword ptr [x]

　　上面的代码比较慢。不仅因为指令数目比较多，而且由于指令不能配对造成的FLID指令被延迟执行。最好用以下代码代替：

推荐的代码：

编译前编译后

double x； fild dword ptr [i]

int i； fstp qword ptr [x]

x = i；

　　在整数运算中计算商和余数时，使用无符号类型比较快。以下这段典型的代码是编译器产生的32位整型数除以4的代码：

　　不好的代码推荐的代码

编译前编译后

int i； mov eax, i

i = i / 4； cdq

and edx, 3

add eax, edx

sar eax, 2

mov i, eax

编译前编译后

unsigned int i； shr i, 2

i = i / 4；

　　总结：

　　无符号类型用于：

　　除法和余数

　　循环计数

　　数组下标

　　有符号类型用于：

　　整型到浮点的转化

　　while VS. for

　　在编程中，我们常常需要用到无限循环，常用的两种方法是while (1) 和 for (；；)。这两种方法效果完全一样，但那一种更好呢？然我们看看它们编译后的代码：

编译前编译后

while (1)； mov eax,1

test eax,eax

je foo+23h

jmp foo+18h

编译前编译后

for (；；)； jmp foo+23h

　　一目了然，for (；；)指令少，不占用寄存器，而且没有判断跳转，比while (1)好。

使用数组型代替指针型

　　使用指针会使编译器很难优化它。因为缺乏有效的指针代码优化的方法，编译器总是假设指针可以访问内存的任意地方，包括分配给其他变量的储存空间。所以为了编译器产生优化得更好的代码，要避免在不必要的地方使用指针。一个典型的例子是访问存放在数组中的数据。C++ 允许使用操作符 [] 或指针来访问数组，使用数组型代码会让优化器减少产生不安全代码的可能性。比如，x[0] 和x[2] 不可能是同一个内存地址，但 *p 和 *q 可能。强烈建议使用数组型，因为这样可能会有意料之外的性能提升。

不好的代码推荐的代码

typedef struct

{

　　float x,y,z,w；

} VERTEX；

typedef struct

{

　　float m[4][4]；

} MATRIX；

void XForm(float* res, const float* v, const float* m, int nNumVerts)

{

　　float dp；

　　int i；

　　　const VERTEX* vv = (VERTEX *)v；

　　　for (i = 0； i <； nNumVerts； i++)

　　{

　　　　dp = vv->；x * *m ++；

　　　　dp += vv->；y * *m ++；

　　　　dp += vv->；z * *m ++；

　　　　dp += vv->；w * *m ++；

　　　　*res ++ = dp；　　　　　　// 写入转换了的 x

　　　　dp = vv->；x * *m ++；

　　　　dp += vv->；y * *m ++；

　　　　dp += vv->；z * *m ++；

　　　　dp += vv->；w * *m ++；

　　　　*res ++ = dp；　　　　　// 写入转换了的 y

　　　　dp = vv->；x * *m ++；

　　　　dp += vv->；y * *m ++；

　　　　dp += vv->；z * *m ++；

　　　　dp += vv->；w * *m ++；

　　　　*res ++ = dp；　　　　// 写入转换了的 z

　　　　dp = vv->；x * *m ++；

　　　　dp += vv->；y * *m ++；

　　　　dp += vv->；z * *m ++；

　　　　dp += vv->；w * *m ++；

　　　　*res ++ = dp；　　　　// 写入转换了的 w

　　　　vv ++；　　　　　　　 // 下一个矢量

　　　　m -= 16；

　　}

typedef struct

{

　　float x,y,z,w；

} VERTEX；

typedef struct

{

　　float m[4][4]；

} MATRIX；

void XForm (float* res, const float* v, const float* m, int nNumVerts)

{

　　int i；

　　const VERTEX* vv = (VERTEX*)v；

　　const MATRIX* mm = (MATRIX*)m；

　　VERTEX* rr = (VERTEX*)res；

　　for (i = 0； i <； nNumVerts； i++)

　　{

　　　　rr->；x = vv->；x * mm->；m[0][0] + vv->；y * mm->；m[0][1]

　　　　　　　　+ vv->；z * mm->；m[0][2] + vv->；w * mm->；m[0][3]；

　　　　rr->；y = vv->；x * mm->；m[1][0] + vv->；y * mm->；m[1][1]

　　　　　　　　+ vv->；z * mm->；m[1][2] + vv->；w * mm->；m[1][3]；

　　　　rr->；z = vv->；x * mm->；m[2][0] + vv->；y * mm->；m[2][1]

　　　　　　　　+ vv->；z * mm->；m[2][2] + vv->；w * mm->；m[2][3]；

　　　　rr->；w = vv->；x * mm->；m[3][0] + vv->；y * mm->；m[3][1]

　　　　　　　　+ vv->；z * mm->；m[3][2] + vv->；w * mm->；m[3][3]；

　　}

　　注意: 源代码的转化是与编译器的代码发生器相结合的。从源代码层次很难控制产生的机器码。依靠编译器和特殊的源代码，有可能指针型代码编译成的机器码比同等条件下的数组型代码运行速度更快。明智的做法是在源代码转化后检查性能是否真正提高了，再选择使用指针型还是数组型。

充分分解小的循环

　　要充分利用CPU的指令缓存，就要充分分解小的循环。特别是当循环体本身很小的时候，分解循环可以提高性能。BTW:很多编译器并不能自动分解循环。

不好的代码推荐的代码

// 3D转化：把矢量 V 和 4x4 矩阵 M 相乘

for (i = 0； i <； 4； i ++)

{

　　r[i] = 0；

　　for (j = 0； j <； 4； j ++)

　　{

　　　　r[i] += M[j][i]*V[j]；

　　}

r[0] = M[0][0]*V[0] + M[1][0]*V[1] + M[2][0]*V[2] + M[3][0]*V[3]；

r[1] = M[0][1]*V[0] + M[1][1]*V[1] + M[2][1]*V[2] + M[3][1]*V[3]；

r[2] = M[0][2]*V[0] + M[1][2]*V[1] + M[2][2]*V[2] + M[3][2]*V[3]；

r[3] = M[0][3]*V[0] + M[1][3]*V[1] + M[2][3]*V[2] + M[3][3]*v[3]；

　　避免没有必要的读写依赖

　　当数据保存到内存时存在读写依赖，即数据必须在正确写入后才能再次读取。虽然AMD Athlon等CPU有加速读写依赖延迟的硬件，允许在要保存的数据被写入内存前读取出来，但是，如果避免了读写依赖并把数据保存在内部寄存器中，速度会更快。在一段很长的又互相依赖的代码链中，避免读写依赖显得尤其重要。如果读写依赖发生在操作数组时，许多编译器不能自动优化代码以避免读写依赖。所以推荐程序员手动去消除读写依赖，举例来说，引进一个可以保存在寄存器中的临时变量。这样可以有很大的性能提升。下面一段代码是一个例子：

　　不好的代码推荐的代码

float x[VECLEN], y[VECLEN], z[VECLEN]；

......

for (unsigned int k = 1； k <； VECLEN； k ++)

{

　　x[k] = x[k-1] + y[k]；

}

for (k = 1； k <； VECLEN； k++)

{

　　x[k] = z[k] * (y[k] - x[k-1])；

}

float x[VECLEN], y[VECLEN], z[VECLEN]；

......

float t(x[0])；

for (unsigned int k = 1； k <； VECLEN； k ++)

{

　　t = t + y[k]；

　　x[k] = t；

}

t = x[0]；

for (k = 1； k <； VECLEN； k ++)

{

　　t = z[k] * (y[k] - t)；

　　x[k] = t；

}

　　Switch 的用法

　　Switch 可能转化成多种不同算法的代码。其中最常见的是跳转表和比较链/树。推荐对case的值依照发生的可能性进行排序，把最有可能的放在第一个，当switch用比较链的方式转化时，这样可以提高性能。此外，在case中推荐使用小的连续的整数，因为在这种情况下，所有的编译器都可以把switch 转化成跳转表。

不好的代码推荐的代码

int days_in_month, short_months, normal_months, long_months；

......

switch (days_in_month)

{

　　case 28:

　　case 29:

　　　　short_months ++；

　　　　break；

　　case 30:

　　　　normal_months ++；

　　　　break；

　　case 31:

　　　　long_months ++；

　　　　break；

　　default:

　　　　cout <；<； "；month has fewer than 28 or more than 31 days"； <；<； endl；

　　　　break；

}

int days_in_month, short_months, normal_months, long_months；

......

switch (days_in_month)

{

　　case 31:

　　　　long_months ++；

　　　　break；

　　case 30:

　　　　normal_months ++；

　　　　break；

　　case 28:

　　case 29:

　　　　short_months ++；

　　　　break；

　　default:

　　　　cout <；<； "；month has fewer than 28 or more than 31 days"； <；<； endl；

　　　　break；

}

　　所有函数都应该有原型定义

　　一般来说，所有函数都应该有原型定义。原型定义可以传达给编译器更多的可能用于优化的信息。

　　尽可能使用常量(const)

　　尽可能使用常量(const)。C++ 标准规定，如果一个const声明的对象的地址不被获取，允许编译器不对它分配储存空间。这样可以使代码更有效率，而且可以生成更好的代码。

提升循环的性能

　　要提升循环的性能，减少多余的常量计算非常有用（比如，不随循环变化的计算）。

　　不好的代码(在for()中包含不变的if()) 推荐的代码

for( i ... )

{

　　if( CONSTANT0 )

　　{

　　　　DoWork0( i )； // 假设这里不改变CONSTANT0的值

　　}

　　else

　　{

　　　　DoWork1( i )； // 假设这里不改变CONSTANT0的值

　　}

if( CONSTANT0 )

{

　　for( i ... )

　　{

　　　　DoWork0( i )；

　　}

else

{

　　for( i ... )

　　{

　　　　DoWork1( i )；

　　}

　　如果已经知道if()的值，这样可以避免重复计算。虽然不好的代码中的分支可以简单地预测，但是由于推荐的代码在进入循环前分支已经确定，就可以减少对分支预测的依赖。　　把本地函数声明为静态的(static)

　　如果一个函数在实现它的文件外未被使用的话，把它声明为静态的(static)以强制使用内部连接。否则，默认的情况下会把函数定义为外部连接。这样可能会影响某些编译器的优化——比如，自动内联。

　　考虑动态内存分配

　　动态内存分配（C++中的"；new"；）可能总是为长的基本类型（四字对齐）返回一个已经对齐的指针。但是如果不能保证对齐，使用以下代码来实现四字对齐。这段代码假设指针可以映射到 long 型。

　　例子

　　double* p = (double*)new BYTE[sizeof(double) * number_of_doubles+7L]；

double* np = (double*)((long(p) + 7L) &； –8L)；

　　现在，你可以使用 np 代替 p 来访问数据。注意：释放储存空间时仍然应该用delete p。

　　使用显式的并行代码

　　尽可能把长的有依赖的代码链分解成几个可以在流水线执行单元中并行执行的没有依赖的代码链。因为浮点操作有很长的潜伏期，所以不管它被映射成 x87 或 3DNow! 指令，这都很重要。很多高级语言，包括C++，并不对产生的浮点表达式重新排序，因为那是一个相当复杂的过程。需要注意的是，重排序的代码和原来的代码在代数上一致并不等价于计算结果一致，因为浮点操作缺乏精确度。在一些情况下，这些优化可能导致意料之外的结果。幸运的是，在大部分情况下，最后结果可能只有最不重要的位（即最低位）是错误的。

　　不好的代码推荐的代码

double a[100], sum；

int i；

sum = 0.0f；

for (i=0； i<；100； i++)

　　sum += a[i]；

double a[100], sum1, sum2, sum3, sum4, sum；

int i；

sum1 = sum2 = sum3 = sum4 = 0.0；

for (i = 0； i <； 100； i += 4)

{

　　sum1 += a[i]；

　　sum2 += a[i+1]；

　　sum3 += a[i+2]；

　　sum4 += a[i+3]；

}

sum = (sum4+sum3)+(sum1+sum2)；

　　要注意的是：使用4 路分解是因为这样使用了4阶段流水线浮点加法，浮点加法的每一个阶段占用一个时钟周期，保证了最大的资源利用率。

提出公共子表达式

　　在某些情况下，C++编译器不能从浮点表达式中提出公共的子表达式，因为这意味着相当于对表达式重新排序。需要特别指出的是，编译器在提取公共子表达式前不能按照代数的等价关系重新安排表达式。这时，程序员要手动地提出公共的子表达式（在VC.net里有一项“全局优化”选项可以完成此工作，但效果就不得而知了）。

推荐的代码

float a, b, c, d, e, f；

...

e = b * c / d；

f = b / d * a；

float a, b, c, d, e, f；

...

const float t(b / d)；

e = c * t；

f = a * t；

推荐的代码

float a, b, c, e, f；

...

e = a / c；

f = b / c；

float a, b, c, e, f；

...

const float t(1.0f / c)；

e = a * t；

f = b * t；

　　结构体成员的布局

　　很多编译器有“使结构体字，双字或四字对齐”的选项。但是，还是需要改善结构体成员的对齐，有些编译器可能分配给结构体成员空间的顺序与他们声明的不同。但是，有些编译器并不提供这些功能，或者效果不好。所以，要在付出最少代价的情况下实现最好的结构体和结构体成员对齐，建议采取这些方法：

　　按类型长度排序

　　把结构体的成员按照它们的类型长度排序，声明成员时把长的类型放在短的前面。

　　把结构体填充成最长类型长度的整倍数

　　把结构体填充成最长类型长度的整倍数。照这样，如果结构体的第一个成员对齐了，所有整个结构体自然也就对齐了。下面的例子演示了如何对结构体成员进行重新排序：

　　不好的代码，普通顺序推荐的代码，新的顺序并手动填充了几个字节

struct

{

　　char a[5]；

　　long k；

　　double x；

} baz；

struct

{

　　double x；

　　long k；

　　char a[5]；

char pad[7]；

} baz；

　　这个规则同样适用于类的成员的布局。

　　按数据类型的长度排序本地变量

　　当编译器分配给本地变量空间时，它们的顺序和它们在源代码中声明的顺序一样，和上一条规则一样，应该把长的变量放在短的变量前面。如果第一个变量对齐了，其它变量就会连续的存放，而且不用填充字节自然就会对齐。有些编译器在分配变量时不会自动改变变量顺序，有些编译器不能产生4字节对齐的栈，所以4字节可能不对齐。下面这个例子演示了本地变量声明的重新排序：

　　不好的代码，普通顺序推荐的代码，改进的顺序

short ga, gu, gi；

long foo, bar；

double x, y, z[3]；

char a, b；

float baz；

double z[3]；

double x, y；

long foo, bar；

float baz；

short ga, gu, gi；

　　避免不必要的整数除法

　　整数除法是整数运算中最慢的，所以应该尽可能避免。一种可能减少整数除法的地方是连除，这里除法可以由乘法代替。这个替换的副作用是有可能在算乘积时会溢出，所以只能在一定范围的除法中使用。

　　不好的代码推荐的代码

int i, j, k, m；

m = i / j / k；

int i, j, k, m；

m = i / (j * k)；

　　把频繁使用的指针型参数拷贝到本地变量

　　避免在函数中频繁使用指针型参数指向的值。因为编译器不知道指针之间是否存在冲突，所以指针型参数往往不能被编译器优化。这样是数据不能被存放在寄存器中，而且明显地占用了内存带宽。注意，很多编译器有“假设不冲突”优化开关（在VC里必须手动添加编译器命令行/Oa或/Ow），这允许编译器假设两个不同的指针总是有不同的内容，这样就不用把指针型参数保存到本地变量。否则，请在函数一开始把指针指向的数据保存到本地变量。如果需要的话，在函数结束前拷贝回去。　　不好的代码推荐的代码

?/ 假设 q != r

void isqrt(unsigned long a, unsigned long* q, unsigned long* r)

{

　　*q = a；

　　if (a >； 0)

　　{

　　　　while (*q >； (*r = a / *q))

　　　　{

　　　　　　*q = (*q + *r) >；>； 1；

　　　　}

　　*r = a - *q * *q；

}

// 假设 q != r

void isqrt(unsigned long a, unsigned long* q, unsigned long* r)

{

　　unsigned long qq, rr；

　　qq = a；

　　if (a >； 0)

　　{

　　　　while (qq >； (rr = a / qq))

　　　　{

　　　　　　qq = (qq + rr) >；>； 1；

　　　　}

　　rr = a - qq * qq；

　　*q = qq；

　　*r = rr；

}

赋值与初始化

先看看以下代码：

class CInt

{

　　int m_i；

public:

　　CInt(int a = 0):m_i(a) { cout <；<； "；CInt"； <；<； endl； }

　　~CInt() { cout <；<； "；~CInt"； <；<； endl； }

　　CInt operator + (const CInt&； a) { return CInt(m_i + a.GetInt())； }

　　void SetInt(const int i)　　{ m_i = i； }

　　int GetInt() const　　　　　　{ return m_i； }

}；

不好的代码推荐的代码

void main()

{

　　CInt a, b, c；

　　a.SetInt(1)；

　　b.SetInt(2)；

　　c = a + b；

}

void main()

{

　　CInt a(1), b(2)；

　　CInt c(a + b)；

}

　　这两段代码所作的事都一样，但那一个更好呢？看看输出结果就会发现，不好的代码输出了四个"；CInt"；和四个"；~CInt"；，而推荐的代码只输出三个。也就是说，第二个例子比第一个例子少生成一次临时对象。Why? 请注意，第一个中的c用的是先声明再赋值的方法，第二个用的是初始化的方法，它们有本质的区别。第一个例子的"；c = a + b"；先生成一个临时对象用来保存a + b的值，再把该临时对象用位拷贝的方法给c赋值，然后临时对象被销毁。这个临时对象就是那个多出来的对象。第二个例子直接用拷贝构造函数的方法对c初始化，不产生临时对象。所以，尽量在需要使用一个对象时才声明，并用初始化的方法赋初值。

　　尽量使用成员初始化列表

　　在初始化类的成员时，尽量使用成员初始化列表而不是传统的赋值方式。

　　不好的代码推荐的代码

籧lass CMyClass

{

　　string strName；

public:

　　CMyClass(const string&； str)；

}；

CMyClass::CMyClass(const string&； str)

{

　　strName = str；

}

class CMyClass

{

　　string strName；

　　int i；

public:

　　CMyClass(const string&； str)；

}；

CMyClass::CMyClass(const string&；str)

　　: strName(str)

{

}

　　不好的例子用的是赋值的方式。这样，strName会先被建立（调用了string的默认构造函数），再由参数str赋值。而推荐的例子用的是成员初始化列表，strName直接构造为str，少调用一次默认构造函数，还少了一些安全隐患。