操作系统大型实验进展（2）-----头文件保护

一、#pragma once（比较常用）

这是一个比较常用的指令,只要在头文件的最开始加入这条指令就能够保证头文件被编译一次

#pragma once用来防止某个头文件被多次include，#ifndef，#define，#endif用来防止某个宏被多次定义。

#pragma once是编译相关，就是说这个编译系统上能用，但在其他编译系统不一定可以，也就是说移植性差，不过现在基本上已经是每个编译器都有这个定义了。

#ifndef，#define，#endif这个是C++语言相关，这是C++语言中的宏定义，通过宏定义避免文件多次编译。所以在所有支持C++语言的编译器上都是有效的，如果写的程序要跨平台，最好使用这种方式

二、#ifndef~#define~#endif

1:#ifndef SALESITEM_H2:

#defineSALESITEM_H3:

// Definition of Sales_itemclass and related functions goes here4:

#endif

头文件应该含有保护符，即使这些头文件不会被其他头文件包含。编写头文件保护符并不困难，而且如果头文件被包含多次，它可以避免难以理解的编译错误。

在编写头文件之前，我们需要引入一些额外的预处理器设施。预处理器允许我们自定义变量。

预处理器变量 的名字在程序中必须是唯一的。任何与预处理器变量相匹配的名字的使用都关联到该预处理器变量。

为了避免名字冲突，预处理器变量经常用全大写字母表示。

预处理器变量有两种状态：已定义或未定义。定义预处理器变量和检测其状态所用的预处理器指示不同。#define指示接受一个名字并定义该名字为预处理器变量。#ifndef 指示检测指定的预处理器变量是否未定义。如果预处理器变量未定义，那么跟在其后的所有指示都被处理，直到出现 #endif。

可以使用这些设施来预防多次包含同一头文件：

#ifndef SALESITEM_H #define SALESITEM_H // Definition of Sales_itemclass and related functions goes here #endif

条件指示

#ifndef SALESITEM_H

测试 SALESITEM_H 预处理器变量是否未定义。如果 SALESITEM_H 未定义，那么 #ifndef 测试成功，跟在#ifndef 后面的所有行都被执行，直到发现 #endif。相反，如果 SALESITEM_H 已定义，那么 #ifndef 指示测试为假，该指示和 #endif 指示间的代码都被忽略。

为了保证头文件在给定的源文件中只处理过一次，我们首先检测 #ifndef。第一次处理头文件时，测试会成功，因为 SALESITEM_H 还未定义。下一条语句定义了 SALESITEM_H。那样的话，如果我们编译的文件恰好又一次包含了该头文件。#ifndef 指示会发现 SALESITEM_H 已经定义，并且忽略该头文件的剩余部分。

头文件应该含有保护符，即使这些头文件不会被其他头文件包含。编写头文件保护符并不困难，而且如果头文件被包含多次，它可以避免难以理解的编译错误。

当没有两个头文件定义和使用同名的预处理器常量时，这个策略相当有效。我们可以为定义在头文件里的实体（如类）命名预处理器变量来避免预处理器变量重名的问题。一个程序只能含有一个名为 Sales_item 的类。通过使用类名来组成头文件和预处理器变量的名字，可以使得很可能只有一个文件将会使用该预处理器变量

三、比较

#pragma once与 #ifndef的区别

为了避免同一个文件被include多次

1 #ifndef方式
2 #pragma once方式

在能够支持这两种方式的编译器上，二者并没有太大的区别，但是两者仍然还是有一些细微的区别。
方式一：

#ifndef __SOMEFILE_H__
#define __SOMEFILE_H__
... ... // 一些声明语句
#endif

方式二：

#pragma once
... ... // 一些声明语句

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

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

方式一由语言支持所以移植性好，方式二可以避免名字冲突