预处理指令详解等资料整理.docx

上传人:b****2 文档编号:24132382 上传时间:2023-05-24 格式:DOCX 页数:34 大小:36.11KB
下载 相关 举报
预处理指令详解等资料整理.docx_第1页
第1页 / 共34页
预处理指令详解等资料整理.docx_第2页
第2页 / 共34页
预处理指令详解等资料整理.docx_第3页
第3页 / 共34页
预处理指令详解等资料整理.docx_第4页
第4页 / 共34页
预处理指令详解等资料整理.docx_第5页
第5页 / 共34页
点击查看更多>>
下载资源
资源描述

预处理指令详解等资料整理.docx

《预处理指令详解等资料整理.docx》由会员分享,可在线阅读,更多相关《预处理指令详解等资料整理.docx(34页珍藏版)》请在冰豆网上搜索。

预处理指令详解等资料整理.docx

预处理指令详解等资料整理

1.#pragma预处理指令详解1

2.导入文本文件时如何指定字段类型7

3.C语言获取系统时间的几种方式10

4.Window里面的一些不一样的13

1.#pragma预处理指令详解

∙在所有的预处理指令中,#Pragma 指令可能是最复杂的了,他的作用是设定编译器的状态或是指示编译器完成一些特定的动作。

#pragma指令对每个编译器给出了一个方法,在保持和C和C++语言完全兼容的情况下,给出主机或操作系统专有的特征。

依据定义,编译指示是机器或操作系统专有的,且对于每个编译器都是不同的。

 

其格式一般为:

       #Pragma Para 

      其中Para 为参数,下面来看一些常用的参数。

  

      

(1)message 参数。

 Message 参数是我最喜欢的一个参数,他能够在编译信息输出窗 

口中输出相应的信息,这对于原始码信息的控制是非常重要的。

其使用方法为:

 

            #Pragma message(“消息文本”) 

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

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

假设我们希望判断自己有没有在原始码的什么地方定义了_X86这个宏能用下面的方法 

            #ifdef _X86 

            #Pragma message(“_X86 macro activated!

”) 

            #endif 

            当我们定义了_X86这个宏以后,应用程式在编译时就会在编译输出窗口里显示“_ 

X86 macro activated!

”。

我们就不会因为不记得自己定义的一些特定的宏而抓耳挠腮了 。

       

    

(2)另一个使用得比较多的pragma参数是code_seg。

格式如:

 

          #pragma code_seg( ["section-name"[,"section-class"] ] ) 

          他能够设置程式中函数代码存放的代码段,当我们研发驱动程式的时候就会使用到他。

  

    (3)#pragma once (比较常用) 

          只要在头文件的最开始加入这条指令就能够确保头文件被编译一次,这条指令实际上在VC6中就已有了,不过考虑到兼容性并没有太多的使用他。

       

    (4)#pragma hdrstop表示预编译头文件到此为止,后面的头文件不进行预编译。

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

   

        有时单元之间有依赖关系,比如单元A依赖单元B,所以单元B要先于单元A编译。

你能用#pragma startup指定编译优先级,如果使用了#pragma package(smart_init) ,BCB就会根据优先级的大小先后编译。

         

    (5)#pragma resource "*.dfm"表示把*.dfm文件中的资源加入工程。

*.dfm中包括窗体 

外观的定义。

           

    (6)#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)。

 

      (7)pragma comment(...) 

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

 

          常用的lib关键字,能帮我们连入一个库文件。

   

每个编译程式能用#pragma指令激活或终止该编译程式支持的一些编译功能。

例如,对循环优化功能:

 

#pragma loop_opt(on)           // 激活 

#pragma loop_opt(off)   // 终止 

有时,程式中会有些函数会使编译器发出你熟知而想忽略的警告,如“Parameter xxx is never used in function xxx”,能这样:

 

#pragma warn ?

100           // Turn off the warning message for warning #100 

int insert_record(REC *r) 

{ /* function body */ } 

#pragma warn +100                       // Turn the warning message for warning #100 back on 

函数会产生一条有唯一特征码100的警告信息,如此可暂时终止该警告。

 

每个编译器对#pragma的实现不同,在一个编译器中有效在别的编译器中几乎无效。

可从编译器的文件中查看。

用#pragmadata_seg建立一个新的数据段并定义共享数据,其具体格式为:

  #pragmadata_seg("shareddata")

  HWNDsharedwnd=NULL;//共享数据

  #pragmadata_seg()

1,#pragmadata_seg()一般用于DLL中。

也就是说,在DLL中定义一个共享的,有名字的数据段。

最关键的是:

这个数据段中的全局变量能被多个进程共享。

否则多个进程之间无法共享DLL中的全局变量。

2,共享数据必须初始化,否则微软编译器会把没有初始化的数据放到.BSS段中,从而导致多个进程之间的共享行为失败。

3。

如果在一个DLL中这么写:

#pragmadata_seg("MyData")

intg_Value;//Notethattheglobalisnotinitialized.

#pragmadata_seg()

DLL提供两个接口函数:

intGetValue()

{

  returng_Value;

}

voidSetValue(intn)

{

  g_Value=n;

}

然后启动两个进程A和B,A和B都调用了这个DLL,如果A调用了SetValue(5);B接着调用intm=GetValue();那么m的值不一定是5,而是个未定义的值。

因为DLL中的全局数据对于每一个调用他的进程而言,是私有的,不能共享的。

如果你对g_Value进行了初始化,那么g_Value就一定会被放进MyData段中。

换句话说,如果A调用了SetValue(5);B接着调用intm=GetValue();那么m的值就一定是5!

这就实现了跨进程之间的数据通信!

1.内存对齐与 struct型数据的内存布局 

当在C中定义了一个结构类型时,它的大小是否等于各字段(field)大小之和?

编译器将如何在内存中放置这些字段?

ANSI C对结构体的内存布局有什么要求?

而我们的程序又能否依赖这种布局?

这些问题或许对不少朋友来说还有点模糊,那么本文就试着探究它们背后的秘密。

 首先,至少有一点可以肯定,那就是ANSI C保证结构体中各字段在内存中出现的位置是随它们的声明顺序依次递增的,并且第一个字段的首地址等于整个结构体实例的首地址。

比如有这样一个结构体:

struct vector{int x,y,z;} s;

int *p,*q,*r;

struct vector *ps;

p = &s.x;

q = &s.y;

r = &s.z;

ps = &s;

assert(p < q);

assert(p < r);

assert(q < r);

assert((int*)ps == p);

// 上述断言一定不会失败

这时,有朋友可能会问:

"标准是否规定相邻字段在内存中也相邻?

"。

 唔,对不起,ANSI C没有做出保证,你的程序在任何时候都不应该依赖这个假设。

那这是否意味着我们永远无法勾勒出一幅更清晰更精确的结构体内存布局图?

哦,当然不是。

不过先让我们从这个问题中暂时抽身,关注一下另一个重要问题————内存对齐。

许多实际的计算机系统对基本类型数据在内存中存放的位置有限制,它们会要求这些数据的首地址的值是某个数k(通常它为4或8)的倍数,这就是所谓的内存对齐,而这个k则被称为该数据类型的对齐模数(alignment modulus)。

当一种类型S的对齐模数与另一种类型T的对齐模数的比值是大于1的整数,我们就称类型S的对齐要求比T强(严格),而称T比S弱(宽松)。

这种强制的要求一来简化了处理器与内存之间传输系统的设计,二来可以提升读取数据的速度。

比如这么一种处理器,它每次读写内存的时候都从某个8倍数的地址开始,一次读出或写入8个字节的数据,假如软件能保证double类型的数据都从8倍数地址开始,那么读或写一个double类型数据就只需要一次内存操作。

否则,我们就可能需要两次内存操作才能完成这个动作,因为数据或许恰好横跨在两个符合对齐要求的8字节内存块上。

某些处理器在数据不满足对齐要求的情况下可能会出错,但是Intel的IA32架构的处理器则不管数据是否对齐都能正确工作。

不过Intel奉劝大家,如果想提升性能,那么所有的程序数据都应该尽可能地对齐。

Win32平台下的微软C编译器(cl.exe for 80x86)在默认情况下采用如下的对齐规则:

 任何基本数据类型T的对齐模数就是T的大小,即sizeof(T)。

比如对于double类型(8字节),就要求该类型数据的地址总是8的倍数,而char类型数据(1字节)则可以从任何一个地址开始。

Linux下的GCC奉行的是另外一套规则(在资料中查得,并未验证,如错误请指正):

任何2字节大小(包括单字节吗?

)的数据类型(比如short)的对齐模数是2,而其它所有超过2字节的数据类型(比如long,double)都以4为对齐模数。

现在回到我们关心的struct上来。

ANSI C规定一种结构类型的大小是它所有字段的大小以及字段之间或字段尾部的填充区大小之和。

嗯?

填充区?

对,这就是为了使结构体字段满足内存对齐要求而额外分配给结构体的空间。

那么结构体本身有什么对齐要求吗?

有的,ANSI C标准规定结构体类型的对齐要求不能比它所有字段中要求最严格的那个宽松,可以更严格(但此非强制要求,VC7.1就仅仅是让它们一样严格)。

我们来看一个例子(以下所有试验的环境是Intel Celeron 2.4G + WIN2000 PRO + vc7.1,内存对齐编译选项是"默认",即不指定/Zp与/pack选项):

typedef struct ms1

{

char a;

int b;

} MS1;

假设MS1按如下方式内存布局(本文所有示意图中的内存地址从左至右递增):

+---------------------------+

| | |

| a | b |

| | |

+---------------------------+

1 Byte 4 byte 

因为MS1中有最强对齐要求的是b字段(int),所以根据编译器的对齐规则以及ANSI C标准,MS1对象的首地址一定是4(int类型的对齐模数)的倍数。

那么上述内存布局中的b字段能满足int类型的对齐要求吗?

嗯,当然不能。

如果你是编译器,你会如何巧妙安排来满足CPU的癖好呢?

呵呵,经过1毫秒的艰苦思考,你一定得出了如下的方案:

_______________________________________

| |\\\\\\\\\\\| |

| a |\\padding\\| b |

| |\\\\\\\\\\\| |

+-------------------------------------+

Bytes:

 1 3 4

这个方案在a与b之间多分配了3个填充(padding)字节,这样当整个struct对象首地址满足4字节的对齐要求时,b字段也一定能满足int型的4字节对齐规定。

那么sizeof(MS1)显然就应该是8,而b字段相对于结构体首地址的偏移就是4。

非常好理解,对吗?

现在我们把MS1中的字段交换一下顺序:

typedef struct ms2

{

int a;

char b;

} MS2;

或许你认为MS2比MS1的情况要简单,它的布局应该就是

_______________________

| | |

| a | b |

| | |

+---------------------+

Bytes:

 4 1 

因为MS2对象同样要满足4字节对齐规定,而此时a的地址与结构体的首地址相等,所以它一定也是4字节对齐。

嗯,分析得有道理,可是却不全面。

让我们来考虑一下定义一个MS2类型的数组会出现什么问题。

C标准保证,任何类型(包括自定义结构类型)的数组所占空间的大小一定等于一个单独的该类型数据的大小乘以数组元素的个数。

换句话说,数组各元素之间不会有空隙。

按照上面的方案,一个MS2数组array的布局就是:

|<- array[1] ->|<- array[2] ->|<- array[3] .....

__________________________________________________________

| | | | |

| a | b | a | b |.............

| | | | |

+----------------------------------------------------------

Bytes:

 4 1 4 1

当数组首地址是4字节对齐时,array[1].a也是4字节对齐,可是array[2].a呢?

array[3].a ....呢?

可见这种方案在定义结构体数组时无法让数组中所有元素的字段都满足对齐规定,必须修改成如下形式:

___________________________________

| | |\\\\\\\\\\\|

| a | b |\\padding\\|

| | |\\\\\\\\\\\|

+---------------------------------+

Bytes:

 4 1 3

现在无论是定义一个单独的MS2变量还是MS2数组,均能保证所有元素的所有字段都满足对齐规定。

那么sizeof(MS2)仍然是8,而a的偏移为0,b的偏移是4。

好的,现在你已经掌握了结构体内存布局的基本准则,尝试分析一个稍微复杂点的类型吧。

typedef struct ms3

{

char a;

short b;

double c;

} MS3;

我想你一定能得出如下正确的布局图:

padding 

|

_____v_________________________________

| |\| |\\\\\\\\\| |

| a |\| b |\padding\| c |

| |\| |\\\\\\\\\| |

+-------------------------------------+

Bytes:

 1 1 2 4 8

sizeof(short)等于2,b字段应从偶数地址开始,所以a的后面填充一个字节,而sizeof(double)等于8,c字段要从8倍数地址开始,前面的a、b字段加上填充字节已经有4 bytes,所以b后面再填充4个字节就可以保证c字段的对齐要求了。

sizeof(MS3)等于16,b的偏移是2,c的偏移是8。

接着看看结构体中字段还是结构类型的情况:

typedef struct ms4

{

char a;

MS3 b;

} MS4;

MS3中内存要求最严格的字段是c,那么MS3类型数据的对齐模数就与double的一致(为8),a字段后面应填充7个字节,因此MS4的布局应该是:

_______________________________________

| |\\\\\\\\\\\| |

| a |\\padding\\| b |

| |\\\\\\\\\\\| |

+-------------------------------------+

Bytes:

 1 7 16

显然,sizeof(MS4)等于24,b的偏移等于8。

在实际开发中,我们可以通过指定/Zp编译选项来更改编译器的对齐规则。

比如指定/Zpn(VC7.1中n可以是1、2、4、8、16)就是告诉编译器最大对齐模数是n。

在这种情况下,所有小于等于n字节的基本数据类型的对齐规则与默认的一样,但是大于n个字节的数据类型的对齐模数被限制为n。

事实上,VC7.1的默认对齐选项就相当于/Zp8。

仔细看看MSDN对这个选项的描述,会发现它郑重告诫了程序员不要在MIPS和Alpha平台上用/Zp1和/Zp2选项,也不要在16位平台上指定/Zp4和/Zp8(想想为什么?

)。

改变编译器的对齐选项,对照程序运行结果重新分析上面4种结构体的内存布局将是一个很好的复习。

到了这里,我们可以回答本文提出的最后一个问题了。

结构体的内存布局依赖于CPU、操作系统、编译器及编译时的对齐选项,而你的程序可能需要运行在多种平台上,你的源代码可能要被不同的人用不同的编译器编译(试想你为别人提供一个开放源码的库),那么除非绝对必需,否则你的程序永远也不要依赖这些诡异的内存布局。

顺便说一下,如果一个程序中的两个模块是用不同的对齐选项分别编译的,那么它很可能会产生一些非常微妙的错误。

如果你的程序确实有很难理解的行为,不防仔细检查一下各个模块的编译选项。

2.导入文本文件时如何指定字段类型

问题:

我有一个文本文件需要导入 Access ,但是文本文件中有一列数据原本是文本,

但是导入数据库后自动变成了“双精度”类型,我该如何让各个字段按我需要的

数据类型生成哪?

如何让 ACCESS 按照我规定的构架、规格从文本文件、XLS文档中导入数据?

 

方法:

用 Schema.ini 文件

作用:

Schema.ini用于提供文本文件中记录的构架信息。

每个 Schema.ini 项都用于指定表的五个特征之一:

1、文本文件名

2、文件格式

3、字段名、字段长度、字段类型

4、字符集

5、特别数据类型转换

======================================================================

指定文件名

文件名要用方括号括起来,例如如果要对 Sample.txt 使用数据构架信息文件,

那么它的对应的项应该是

[Sample.txt] 

=======================================================================

指定文件格式

格式说明         表格式               Schema.ini 格式描述 

Tab 制表符分隔   文件中的字段用制表符分隔     Format=TabDelimited 

CSV 分隔         文件中的字段用逗号来分隔    Format=CSVDelimited 

自定义分隔       文件中的字段可以用任何字符   Format=Delimited(自定义分隔符)

                 来分隔,所有的字符都可以

                 用来分隔,包括空格,但是

                双引号 ( " ) 除外 

                - 或者没有分隔符 -           Format=Delimited( )

固定宽度         文件中的字段为固定长度  

======================

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高中教育 > 高中教育

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1