Linux之#pragma的用法

预编译指令#pragma的用法

最近在看开源项目中的代码时，发现许多地方都用到了#pragma的程序。因此，就问了下谷歌老师，总结了下＃pragma预编译指令的常用用法，现在和大家分享下。

一.#pragma最常用的方法

1. #progma pack（n）

1>功能：

使用#progma pack预编译指令可以改变编译器的默认值（不是绝对的，有些编译器只能是固定的数据对齐方式）。

2>说明

大多数情况下，我们写程序时候并不考虑对齐的问题，因为编译器会替我们选择对的策略。大多数编译器都是默认四字节对齐方式。

大家可以看一个程序就明白了：

程序A:

#include<stdio.h>

struct A

{

int a;

char b;

short c;

};

int main()

{

int d;

d= sizeof (struct A);

printf(“theleng=%d\n”,d);

return 0;

}

注：

(1)一般现在我们用的都是32位的处理器，vc编译器默认的对齐字节数目是4字节。在gcc下默认为以结构体中最大类型的变量为字节对齐方式。

结构体A中包含了4字节长度的int一个，1字节长度的char一个和2字节长度的short型数据一个。所以A用到的空间应该是7字节。但是因为编译器要对数据成员在空间上进行对齐。所以使用sizeof(strcut A)值为8《a 占4个字节，b占一个字节，c占两个字节，因此编译器会把b和C放在一个4字节之内，因此结构体A占8个字节》

(2)现在我们讨论下字节对齐的好处：

现代计算机中内存空间都是按照byte划分的，从理论上讲似乎对任何类型的变量的访问可以从任何地址开始，但实际情况是在访问特定变量的时候经常在特定的内存地址访问，这就需要各类型数据按照一定的规则在空间上排列，而不是顺序的一个接一个的排放，这就是对齐

对齐的作用和原因：各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。其他平台可能没有这种情况，但是最常见的是如果不按照适合其平台要求对数据存放进行对齐，会在存取效率上带来损失

比如有些平台每次读都是从偶地址开始，如果一个int型（假设为32位系统）如果存放在偶地址开始的地方，那么一个读周期就可以读出，而如果存放在奇地址开始的地方，就可能会需要2个读周期，并对两次读出的结果的高低字节进行拼凑才能得到该int数据。显然在读取效率上下降很多。这也是空间和时间的博弈

3>How to Use?

使用方法举例：

#pragma pack(push) //保存以前的对齐状态，push是将以前的对齐状态压入栈

#pragma pack(1) //指定新的对齐状态，1个字节

//定义你的结构

//…………

#pragma pack(pop) //弹出栈，恢复以前的对齐状态

现在我们把刚才的程序修改下：

程序B:

#include<stdio.h>

#pragma pack(push)

#pragma pack(1)

struct A

{

int a;

char b;

short c;

};

#pragma pack(pop);

int main()

{

int d;

d = sizeof (struct A);

printf(“theleng=%d\n”,d);

return 0;

}

此时因为是按一字节对齐，因此结构体A总共占用7个字节。

2. #pragma message(“字符串常量”)

1>功能：

当编译器遇到这条指令时就在编译输出窗口中将消息文本打印出来

2>说明：

当我们在程序中定义了许多宏来控制源代码版本的时候，我们自己有可能都会忘记有没有正确的设置这些宏，此时我们可以用这条指令在编译的时候就进行检查。

3>How to use?

#pragma message(“macro activated!”)

注：此处在message()后不加分号。

3.#pragma once

1>功能：

只要在头文件的最开始加入这条指令就能够保证头文件被编译一次

2>说明：#pragma once与#ifndef的区别

（1）相同点：

为了避免同一个文件被include多次，#ifndef方式和#pragma once方式（前提是编译器能同时支持两种方式的编译器上），两者并没有多太大的区别。

（2）两者的使用方法：

方法一：

#ifndef __TIGER_H__

#define __TIGER_H__

……….//一些声明语句

#endif

方法二：

#pragma once

………//一些声明语句

（3）两者的区别：

#ifndef 的方式依赖于宏名不能冲突，这不光可以保证同一个文件不会被包含多次，也能保证内容完全相同的两个头文件不会被不小心同时包含。当然，缺点就是如果不同头文件的宏名不小心“撞车”，可能就会导致头文件明明存在，编译器却硬说找不到声明的状况。

#pragma once则由编译器提供保证：同一个文件不会被包含多次。注意此处说的同一个文件是指物理上的一个文件，而不是指内容相同的两个文件。带来的好处就是；你不必再费劲想个宏名了，当然也就不会出现宏名碰撞引发的奇怪问题。对应的缺点就是如果某个头文件有多份拷贝，本方法不能保证他们不被重复包含。当然，相比宏名碰撞引发的“找不到声明”的问题，重复包含更容易被发现并修正。

对于#pragmaonce,根据MSDN解说，能够防止一个文件被多次包含。与#ifndef #define #endif形式的文件保护相比，前者是平台相关的，可移植性比较差，但是它效率更高，因为它不需要去打开包含的文件，就可以判断这个文件有没有被包含。当然这个工作是系统帮我们完成的。后者的优点在于它是语言相关的特性，所以可移植性好。但是在包含一个文件的时候，只有打开这个文件，根据文件的保护宏是否已经被定义来判断此文件是否已经被包含过。效率相对较低。当然在＃include的时候，程序员也可以自己判断所要包含的文件的保护宏是否已经被定义，来决定是否要包含这个文件。类似下面的代码：

#ifndef FILE_H_

＃include "file.h"

#endif

这样作可以得到较高的效率，而且保证可移植性。但是文件之间的依赖性较高，如果一个文件的保护宏改变的话，所有使用如上形式包含这个文件的文件都要修改。有悖于模块化的思想。

二.#pragma的一些其他方法

1.#pragma参数是code_seg。

1>格式：

#pragma code_seg( [ [ { push | pop}, ] [ identifier, ]] [ "segment-name" [, "segment-class" ] )

2>功能：

它能够设置程序中函数代码存放的代码段，当我们开发驱动程序的时候就会使用到它

3>说明：

该指令用来指定函数在.obj文件中存放的节,观察OBJ文件可以使用VC自带的dumpbin命令行程序,函数在.obj文件中默认的存放节为.text节 ，如果code_seg没有带参数的话,则函数存放在.text节中 。push(可选参数) 将一个记录放到内部编译器的堆栈中,可选参数可以为一个标识符或者节名。pop(可选参数) 将一个记录从堆栈顶端弹出,该记录可以为一个标识符或者节名 。identifier (可选参数) 当使用push指令时,为压入堆栈的记录指派的一个标识符,当该标识符被删除的时候和其相关的堆栈中的记录将被弹出堆栈
。"segment-name"(可选参数) 表示函数存放的节名

3>实例：

//默认情况下,函数被存放在.text节中

void func1() { // stored in .text

}

//将函数存放在.my_data1节中

#pragma code_seg(".my_data1")

void func2() { // stored in my_data1

}

//r1为标识符,将函数放入.my_data2节中

#pragma code_seg(push, r1, ".my_data2")

void func3() { // stored in my_data2

}

int main() {

}

2.#pragma hdrstop

1>功能：

表示预编译头文件到此为止，后面的头文件不进行预编译，BCB可以预编译头文件以加快链接的速度，但如果所有头文件都进行预编译又可能占太多磁盘空间，所以使用这个选项排除一些头文件。

有时单元之间有依赖关系，比如单元A依赖单元B，所以单元B要先于单元A编译。你可以用#pragma startup指定编译优先级，如果使用了#pragma package(smart_init) ，BCB就会根据优先级的大小先后编译。

3. #pragma warning

1>功能：

该指令允许有选择性的修改编译器的警告消息的行为

2>指令格式：

#pragma warning( warning-specifier :warning-number-list [; warning-specifier : warning-number-list...]

#pragma warning( push[ ,n ] )

#pragma warning( pop )

3>主要用到的警告表示有如下几个:

once:只显示一次(警告/错误等)消息

default:重置编译器的警告行为到默认状态

1,2,3,4:四个警告级别

disable:禁止指定的警告信息

error:将指定的警告信息作为错误报告

如果大家对上面的解释不是很理解,可以参考一下下面的例子及说明

#pragma warning( disable : 4507 34; once : 4385; error: 164 )

等价于：

#pragma warning(disable:4507 34) // 不显示4507和34号警告信息

#pragma warning(once:4385) // 4385号警告信息仅报告一次

#pragma warning(error:164) // 把164号警告信息作为一个错误。

同时这个pragma warning 也支持如下格式：

#pragma warning( push [ ,n ] )

#pragma warning( pop )

这里n代表一个警告等级(1---4)。

#pragma warning( push )保存所有警告信息的现有的警告状态。

#pragma warning( push, n)保存所有警告信息的现有的警告状态，并且把全局警告

等级设定为n。

#pragma warning( pop )向栈中弹出最后一个警告信息，在入栈和出栈之间所作的

一切改动取消。例如：

#pragma warning( push )

#pragma warning( disable : 4705 )

#pragma warning( disable : 4706 )

#pragma warning( disable : 4707 )

#pragma warning( pop )

在这段代码的最后，重新保存所有的警告信息(包括4705，4706和4707)

在使用标准C++进行编程的时候经常会得到很多的警告信息,而这些警告信息都是不必要的提示,

所以我们可以使用#pragma warning(disable:4786)来禁止该类型的警告

在vc中使用ADO的时候也会得到不必要的警告信息,这个时候我们可以通过

#pragma warning(disable:4146)来消除该类型的警告信息

4.# pragma comment(...)

1>功能：

该指令将一个注释记录放入一个对象文件或可执行文件中。

2>格式：

#pragma comment( "comment-type" [,commentstring] )

comment-type(注释类型):可以指定为五种预定义的标识符的其中一种

五种预定义的标识符为:

（1）compiler:将编译器的版本号和名称放入目标文件中,本条注释记录将被编译器忽略，如果你为该记录类型提供了commentstring参数,编译器将会产生一个警告

例如:#pragma comment( compiler )

（2）exestr:将commentstring参数放入目标文件中,在链接的时候这个字符串将被放入到可执行文件中,当操作系统加载可执行文件的时候,该参数字符串不会被加载到内存中.但是,该字符串可以被dumpbin之类的程序查找出并打印出来,你可以用这个标识符将版本号码之类的信息嵌入到可执行文件中!

(3)lib:这是一个非常常用的关键字,用来将一个库文件链接到目标文件中

常用的lib关键字，可以帮我们连入一个库文件。

例如:

#pragma comment(lib, "user32.lib")

该指令用来将user32.lib库文件加入到本工程中

linker:将一个链接选项放入目标文件中,你可以使用这个指令来代替由命令行传入的或者在开发环境中

设置的链接选项,你可以指定/include选项来强制包含某个对象,例如:

#pragma comment(linker, "/include:__mySymbol")

你可以在程序中设置下列链接选项

/DEFAULTLIB

/EXPORT

/INCLUDE

/MERGE

/SECTION

这些选项在这里就不一一说明了,详细信息请看msdn!

5.#pragma resource"*.dfm"

1>功能：

表示把*.dfm文件中的资源加入工程。*.dfm中包括窗体外观的定义。