预处理与宏的巧妙用法

 

刚接触到 MFC 编程的人往往会被 MFC 向导生成的各种宏定义和预处理指令所吓倒，但是预处理和宏定义又是 C 语言的一个强大工具。使用它们可以进行简单的源代码控制，版本控制，预警或者完成一些特殊的功能。

一个经典的例子
  使用预处理与宏定义最经典的例子莫过于加在一个头文件中以避免头文件被两次编译。

试想有一个文件 headerfile.h 它被包含在 headerfile1.h 中，同时在 headerfile2.h 中也被包含了，现有一个 CPP 文件， implement.cpp 包含了 headerfile1.h 和 headerfile2.h ：

#include “headerfile1.h”
#include “headerfile2.h”

假设 headerfile.h 中定义了一个全局变量 iglobal 。

int iglobal;
　　在编译的时候编译器两次编译 headerfile ，也就会发现 iglobal 被定义了两次，这时就会发生变量重定义的编译错误。
　　传统的解决办法是使用 #ifdef 以及 #endif 来避免头文件的重复编译，在上面的例子中，只需要加上这么几行：

#ifndef smartnose_2002_6_21_headerfile_h
#define smartnose_2002_6_21_headerfile_h
int iglobal;
#endif
　　仔细的考虑上面的宏定义，会发现当编译器编译过一次 headerfile.h 以后， smartnose_2002_6_21_headerfile_h 这个宏就被定义了，以后对 headerfile.h 的编译都会跳过 int iglobal 这一行。当然 smartnose_2002_6_21_headerfile_h 这个宏是可以任意定义的，但是这个宏本身不能和其它文件中定义的宏重复，所以 MFC 在自动生成的文件中总是使用一个随机产生的长度非常长的宏，但这没有必要，建议在这个宏中加入一些有意义的信息，比方作者，文件名，文件创建时间等等，因为我们有时候会忘记在注释中加入这些信息。

　　在 VC.Net 中我们不会再看见这些宏定义了，因为在这里会普遍使用一个预处理指令：

#pragma once
　　只要在头文件的最开始加入这条指令就能够保证头文件被编译一次，这条指令实际上在 VC6 中就已经有了，但是考虑到兼容性并没有太多的使用它。

　　源代码版本控制
　　当我们为许多平台开发多个版本的时候预编译指令和宏定义也能够帮忙。假设现在为 WINDOWS 和 LINUX 开发了一套 软件 ，由于这两种系统的不同，不得不在 程序 控制源代码的版本。比方 内存 的分配，可以在 LINUX 上使用标准 C 的 malloc 函数，但是希望在 WINDOWS 上使用 HeapAlloc API 。下面的代码演示了这种情况：

main()
{
………………..
#ifdef _WINDOWS_PLATFORM
HeapAlloc(5);
#else
malloc(5);
#endif
………………..
}
　　当在 WINDOWS 平台上编译此程序的时候，只需要定义 _WINDOWS_PLATFORM 这个宏，那么 HeapAlloc 这条语句就能够起作用了。这样就能够在同一个文件中为不同的平台实现不同版本的代码，同时保持程序的良好结构。在许多情况下，还可以为一个方法使用不同的算法，然后用宏定义来针对不同的情况选择其中的一个进行编译。这在 MFC 应用程序中是使用得最多的。最明显的就是文件中经常存在的

#ifdef _DEBUG

…………………….some code………..

#endif
　　这样的代码，这些代码在应用程序的调试版（ DEBUG ）中会发挥其作用。

#Pragma 指令
　　在所有的预处理指令中， #Pragma 指令可能是最复杂的了，它的作用是设定编译器的状态或者是指示编译器完成一些特定的动作。其格式一般为
　　 #Pragma Para
　　其中 Para 为参数，下面来看一些常用的参数。
　　 message 参数。 Message 参数能够在编译信息输出窗口中输出相应的信息，这对于源代码信息的控制是非常重要的。其使用方法为：
#Pragma message( “消息文本” )
　　当编译器遇到这条指令时就在编译输出窗口中将消息文本打印出来。
　　当在程序中定义了许多宏来控制源代码版本的时候，自己有可能都会忘记有没有正确的设置这些宏，此时可以用这条指令在编译的时候就进行检查。希望判断自己有没有在源代码的什么地方定义了 _X86 这个宏可以用下面的方法

#ifdef _X86
#Pragma message(“_X86 macro activated!”)
#endif
　　当定义了 _X86 这个宏以后，应用程序在编译时就会在编译输出窗口里 显示“_X86 macro activated! ”。就不会因为不记得自己定义的一些特定的宏而抓耳挠腮了。

　　另一个使用得比较多的 pragma 参数是 code_seg 。格式如：

#pragma code_seg( ["section-name"[,"section-class"] ] )
　　它能够设置程序中函数代码存放的代码段，当开发 驱动 程序的时候就会使用到它。

　　最后一个比较常用的就是上面所说的 #pragma once 指令了。

VC 预定义的宏
　　在 VC 中有一类宏并不是由用户用 #define 语句定义的，而是编译器本身就能够识别它们。这些宏的作用也是相当大的。 MFC 中使用得最频繁的一个 :__FILE__ 。
　　当编译器遇到这个宏时就把它展开成当前被编译文件的文件名。可以想到可以用它来做什么，当应用程序发生错误时，可以报告这个错误发生的程序代码在哪个文件里，比方在文件 test.cpp 中有这样的代码：

try
{
char * p=new(char[10]);
}
catch(CException *e )
{
TRACE(“ there is an error in file: %s/n”,__FILE__);
}
　　在程序运行的时候，如果内存分配出现了错误，那么在调试窗口中会出现 there is an error in file: test.cpp 这句话，当然，还可以把这个错误信息显示在别的地方。
　　与 __FILE__ 宏定义一样，还有一个宏记录了当前代码所在的行数，这个宏是 __LINE__ 。使用上面的两个宏，可以写出一个类似于 VC 提供的 ASSERT 语句。下面是方法

#define MyAssert(x) /
if(!(x)) /
MessageBox(__FILE__,__LINE__,NULL,MB_OK);

   在应用程序中可以象使用 ASSERT 语句一样使用它，在错误发生时，它会弹出一个对话框，其标题和内容告诉了我们错误发生的文件和代码行号，方便我们的调试，这对于不能使用 ASSERT 语句的项目来说是非常有用的。
　　除了这两个宏以外，还有记录编译时间的 __TIME__ ，记录日期的 __DATE__ ，以及记录文件修改时间的 __TIMESTAMP__ 宏。
　　使用这些预定义的宏，我们几乎可以生成和 VC 能够生成的一样完整的源代码信息报表。

　　翻开 MFC 和 Linux 的源代码，宏定义几乎占据了半边天，消息映射，队列操作，平台移植，版本管理，甚至内核模块的拆卸安装都用宏定义完成。毫不夸张的说，有些文件甚至就只能看见宏定义。所以学习宏定义，熟练的使用宏定义对于学习 C 语言乃至 VC 都是非常关键的。


　 ## 连接符与 # 符
　　 ## 连接符号由两个井号组成，其功能是在带参数的宏定义中将两个子串 (token) 联接起来，从而形成一个新的子串。但它不可以是第一个或者最后一个子串。所谓的子串 (token) 就是指编译器能够识别的最小语法单元。具体的定义在编译原理里有详尽的解释，但不知道也无所谓。同时值得注意的是 # 符是把传递过来的参数当成字符串进行替代。

　　假设程序中已经定义了这样一个带参数的宏：
#define paster( n ) printf( "token" #n " = %d", token##n )
　　同时又定义了一个整形变量：
int token9 = 9;
　　现在在主程序中以下面的方式调用这个宏：
paster( 9 );
　　那么在编译时，上面的这句话被扩展为：
printf( "token" "9" " = %d", token9 );

　　注意到在这个例子中， paster(9); 中的这个” 9 ”被原封不动的当成了一个字符串，与” token ”连接在了一起，从而成为了 token9 。而 #n 也被” 9 ”所替代。
　　可想而知，上面程序运行的结果就是在屏幕上打印出 token9=9

Linux 的怪圈
　　在刚开始阅读 Linux 的时候有一个小小的宏让人百思不得其解：
#define wait_event(wq,condition) /
do{ /
if(condition) /
break; /
__wait_event(wq,condition); /
}while(0)

　　这是一个奇怪的循环，它根本就只会运行一次，为什么不去掉外面的 do{..}while 结构呢？原来这也是非常巧妙的技巧。在工程中可能经常会引起麻烦，而上面的定义能够保证这些麻烦不会出现。下面是解释：
　　假设有这样一个宏定义
#define macro(condition) /
if(condition) dosomething();

　　现在在程序中这样使用这个宏：
if(temp)
macro(i);
else
doanotherthing();

　　一切看起来很正常，但是仔细想想。这个宏会展开成：
if(temp)
if(condition) dosomething();
else
doanotherthing();
　　这时的 else 不是与第一个 if 语句匹配，而是错误的与第二个 if 语句进行了匹配，编译通过了，但是运行的结果一定是错误的。

　　为了避免这个错误，使用 do{ … .}while(0) 把它包裹起来，成为一个独立的语法单元，从而不会与上下文发生混淆。同时因为绝大多数的编译器都能够识别 do{ … }while(0) 这种无用的循环并进行优化，所以使用这种方法也不会导致程序的性能降低。

　　几个小小的警告
　　正如微软声称的一样，宏定义与预编译器指令是强大的，但是它又使得程序难以调试。所以在定义宏的时候不要节省你的字符串，一定要力争完整的描述这个宏的功能。同时在定义宏的时候如有必要（比方使用了 if 语句）就要使用 do{ … }while(0) 将它封闭起来。在宏定义的时候一定要注意各个宏之间的相互依赖关系，尽量避免这种依赖关系的存在。下面就有这样一个例子。

　　设有一个静态数组组成的整型队列，在定义中使用了这样的方法： int array[]={5, 6, 7, 8};
　　我们还需要在程序中遍历这个数组。通常的做法是使用一个宏定义
#define ELE_NUM 4
…………………………..
……………………………..

for(int I=0;I<ELE_NUM;I++)
{
cout<<array[I];
}
　　由于某种偶然的原因，我们删除了定义中的一个元素，使它变成：
array[]={5,6,7}
　　而却忘了修改 ELE_NUM 的值。那么在上面的代码中马上就会发生访问异常，程序崩溃。然后是彻夜不眠的调试，最后发现问题出在这个宏定义上。解决这个问题的方法是不使用
array[]={ … .} 这样的定义，而显式的申明数组的大小：
array[ELE_NUM]={….}
　　这样在改动数组定义的时候，我们就不会不记得去改宏定义了。总之，就是在使用宏定义的时候能够用宏定义的地方统统都用上。