C++ header files is a rather mundane topic by most standards. Talking about header files is not as interesting as discussing complex search algorithms or debating design patterns . It’s not an academically stimulating subject to teach, so most CS programs do not emphasize header file design in their courses.

However, not having the correct header file design decisions can have significant ramifications on your project in terms of increases build times, compilation fiascos, code maintainability issues and plain information leakage. The larges your C++ project is, the more important this becomes.

Here’s a short description of the top 10 header file issues that can crop up if you’re not careful and how to avoid them.

Mistake # 1: Not using “include guards” in a header file. 错误＃1：不使用“包控制”在头文件。

When the preprocessor sees a #include, it replaces the #include with the contents of the specified header. Using a include guard , you can prevent a header file being included multiple times during the compilation process. The most common way to define an include guard is as follows:

当预处理器会看到一个的#include，它用指定的头的内容的#include。使用包括后卫，可以防止一个头文件在编译过程中被包含多次。以限定包括防护装置的最常见的方式是如下：

//File: Aircraft.h
#ifndef AIRCRAFT_H
#define AIRCRAFT_H
 
\\the entire file
 
#endif

You usually name your #include guard the same as the name of your header file.

There are two main problems that #include guards help solve.

1. It can help prevent danger circular references between header files which can cause weird compilation failures.

Consider the following example where main.cpp includes both Airbus.h and Boeing.h:

你通常命名include防范与您的头文件的名称。
有迹象表明，＃包括警卫帮助解决两个主要问题。
1.它可以帮助防止头文件这可能会导致奇怪的编译错误的危险循环引用。
看看下面的例子，其中的main.cpp包括Airbus.h和Boeing.h：

//File: Airbus.h
#include "Boeing.h"
namespace Airbus
{
	class Carrier
	{
		Carrier();
		~Carrier();
	};
}
 
//File: Boeing.h
#include "Airbus.h"
namespace Boeing
{
	class Carrier
	{
		Carrier();
		~Carrier();
	};
}
 
// main.cpp : Defines the entry point for the console application.
#include "stdafx.h"
#include "Boeing.h"
#include "Airbus.h"
 
int main(){
    return 0;
}

Compiling the code above gives the following error:

1>c:\users\user\documents\visual studio 2015\projects\smartpointers\headerfiles\airbus.h(2): fatal error C1014: too many include files: depth = 1024

If you’re in a large project with hundreds of include files, it might take some digging to find it out. If you’re using VS2015, you’re in luck because there’s an option to show the include order : Right Click the Project -> Properties -> C/C++ -> Advanced -> Show Includes. If you turn this on, you’ll see the following in the output window:

如果你在一个大的项目是数以百计的包含文件，它可能需要一些挖掘找到它。如果你使用VS2015，你很幸运，因为有显示包括订单的选项：右键单击项目 - >属性 - > C / C ++ - >高级 - >显示包括。如果打开这个选项，你会看到在输出窗口中以下内容：

Looking at this you can easily tell that there’s a circular reference between Boeing.h and Airbus.h. Fortunately, include guards can help fix the problem. The revised piece of code is below.

看着这个你可以很容易地告诉大家，有Boeing.h和Airbus.h之间的循环引用。幸运的是，包括守卫可以帮助解决这个问题。代码修改后的一段如下。

//File: Airbus.h
#ifndef AIRBUS_H
#define AIRBUS_H
 
#include "Boeing.h"
 
namespace Airbus
{
	class Carrier
	{
		Carrier();
		~Carrier();
	};
}
#endif
 
//File: Boeing.h
#ifndef BOEING_H
#define BOEING_H
 
#include "Airbus.h"
namespace Boeing
{
	class Carrier
	{
		Carrier();
		~Carrier();
	};
}
#endif
 
// main.cpp : Defines the entry point for the console application.
//
 
#include "stdafx.h"
#include "Boeing.h"
#include "Airbus.h"
 
int main(){
    return 0;
 
}

2. In the absence of an include guard, a file will need to be processed multiple times and can cause significant build delays in large systems.

2.在没有包括护罩，一个文件将需要多次处理，并可能导致在大型系统显著生成延迟。

Recommendation: Always use an include guard as shown above to optimize build times and avoid weird build errors. If your compiler supports and optimized #pragma once as an include guard mechanism, you should use that because it is usually more performant and less error prone than using an explicit include guard. For example, a lot of our internal code uses the following convention for public header files. Notice that if we‘re on a MS compiler where _MSC_VER is defined, we‘ll use the #pragma directive which is supported and optimized by the compiler.

建议：请始终使用如上图所示，优化生成时间，避免怪异的生成错误的包括后卫。如果你的编译器支持和优化的#pragma一次作为一个include防范机制，你应该使用，因为它通常是更好的性能和更小的误差比使用显式俯卧包括后卫。例如，很多我们的内部代码使用公共头文件下列约定。请注意，如果我们在哪里_MSC_VER定义一个MS的编译器，我们将使用它支持和编译器优化#pragma指令。

#ifndef HEADER_FILE
#define HEADER_FILE
 
#ifdef _MSC_VER
#pragma once
#endif  // _MSC_VER
 
// Contents of the header file here
 
#endif  // HEADER_FILE

http://blog.csdn.net/sergeycao/article/details/52537865

MISTAKE # 2: Incorporating "using namespace" statements at top level in a header file

Headers should define only the names that are part of the interface, not names used in its own implementation. However, a using directive at top level in a header file injects names into every file that includes the header.

This can cause multiple issues:

1. It is not possible for a consumer of your header file to undo the namespace include – thus they are forced to live with your namespace using decision, which is undesirable.
2. It dramatically increases the chance of naming collissions that namespaces were meant to solve in the first place.
3. It is possible that a working version of the program will fail to compile when a new version of the library is introduced. This happens if the new version introduces a name that conflicts with a name that the application is using from another library.
4. The “using namespace” part of the code takes effect from the point where it appears in the code that included your header, meaning that any code appearing before that might get treated differently from any code appearing after that point.

Recommendations:

1. Try to avoid putting any using namespace declarations in your header files. If you absolutely need some namespace objects to get your headers to compile, please use the fully qualified names (Eg. std::cout , std::string )in the header files.

1.尽量避免将任何使用空间声明在你的头文件。如果你绝对需要一些空间物品，让您的头编译，请在头文件中使用完全合格的名称（如：性病::法院，性病::字符串）。

//File:MyHeader.h:
class MyClass
{   
private:
    Microsoft::WRL::ComPtr<iunknown> _parent;
    Microsoft::WRL::ComPtr<iunknown> _child;
}
</iunknown></iunknown>

2. If recommendation #1 above causes too much code clutter – restrict your “using namespace” usage to within the class or namespace defined in the header file. Another option is using scoped aliases in your header files as shown below.

2.如果建议1以上引起太多的代码混乱 - 限制你的“使用命名空间”的使用在头文件中定义的类或命名空间内。如下图所示另一种选择是在头文件中使用范围的别名。

//File:MyHeader.h:
 
class MyClass
{
namespace wrl = Microsoft::WRL; // note the aliasing here !
private:
    wrl::ComPtr<iunknown> _parent;
    wrl::ComPtr<iunknown> _child;
}
</iunknown></iunknown>

http://blog.csdn.net/sergeycao/article/details/5253