C++ 헤더 파일의 포함 순서에 관한 연구

1. "Google C++ 프로그래밍 스타일 가이드"의 관점

회사에서는 코딩 표준을 홍보하고 있으며, 리더는 "Google C++ 프로그래밍 스타일 가이드"를 기본적으로 사용하자고 제안했습니다. 그 중 "Google C++ 프로그래밍 스타일 가이드"에는 헤더 파일이 포함되는 순서가 다음과 같습니다.

Names and Order of Includes
link ▽Use standard order for readability and to avoid hidden dependencies:C library, C++ library, other libraries’ .h, your project’s .h.
All of a project’s header files should belisted as descendants of the project’s source directory without use of UNIXdirectory shortcuts . 
(the current directory) or .. (the parent directory). Forexample, google-awesome-project/src/base/logging.h should be included as
#include “base/logging.h”
In dir/foo.cc or dir/foo_test.cc, whosemain purpose is to implement or test the stuff in dir2/foo2.h, order yourincludes as follows:
dir2/foo2.h (preferred location — seedetails below).
C system files.
C++ system files.
Other libraries’ .h files.
Your project’s .h files.
The preferred ordering reduces hiddendependencies. We want every header file to be compilable on its own. 
Theeasiest way to achieve this is to make sure that every one of them is the first.h file #included in some .cc.
dir/foo.cc and dir2/foo2.h are often in thesame directory (e.g. base/basictypes_test.cc and base/basictypes.h), but can bein different directories too.
Within each section it is nice to order theincludes alphabetically.
For example, the includes ingoogle-awesome-project/src/foo/internal/fooserver.cc might look like this:
#include "foo/public/fooserver.h"  // Preferred location.
#include <sys/types.h>
#include <unistd.h>
#include <hash_map>
#include <vector>
#include "base/basictypes.h"
#include"base/commandlineflags.h"
#include "foo/public/bar.h"

여기서는 위 내용에 대해 제가 이해한 내용에 대해 이야기하겠습니다. 부적절하면 친구들에게 수정 사항을 문의하세요):

1. 가독성을 높이고 암시적 종속성을 피하기 위해 다음 순서를 사용해야 합니다: C 표준 라이브러리 , C++ 표준 라이브러리 및 기타 라이브러리. 헤더 파일, 자신의 프로젝트의 헤더 파일. 그러나 선호하는 헤더 파일이 먼저 포함됩니다. 즉, 예를 들어 a.cpp 파일에는 a.h가 먼저 포함되어야 합니다. 헤더 파일과 구현 파일이 일치하는지 확인하면서 숨겨진 종속성을 줄이려면 헤더 파일을 선호하세요. 구체적인 예는 다음과 같습니다. google-awesome-project/src/foo/internal/fooserver.cc인 cc 파일(Linux 플랫폼에서 cpp 파일의 접미사는 cc입니다)이 있는 경우 헤더 파일의 순서는 다음과 같습니다.

#include <sys/types.h>  
#include <unistd.h>  
  
#include <hash_map>  
#include <vector>  
  
#include "base/basictypes.h"  
#include "base/commandlineflags.h"  
#include "foo/public/bar.h"

2. 헤더 파일을 포함할 때 해당 헤더 파일이 있는 프로젝트의 폴더 이름을 추가해야 합니다. 그러한 프로젝트 기반이 있고 그 안에 login.h가 있는 경우 이 헤더 파일의 외부 포함은 다음과 같이 작성되어야 합니다.

#include "logging 대신 #include "base/logging.h" .h"

여기서 볼 수 있는 것은 "Google C++ 프로그래밍"입니다. 스타일 가이드에서 옹호하는 원칙 뒤에 숨은 목적은 다음과 같습니다.

1. 숨겨진 종속성을 줄이고 헤더 파일을 구현 파일과 일치시키려면 기본 설정을 먼저 포함해야 합니다(즉, 해당 헤더 파일).

2. 선호사항 외에 일반사항부터 세부사항까지 원칙을 따릅니다. 하지만 "Google C++ 프로그래밍 스타일 가이드"의 순서: C 표준 라이브러리, C++ 표준 라이브러리, 다른 라이브러리의 헤더 파일, 자신의 프로젝트 헤더 파일은 첫 번째 항목인 운영 체제 수준 헤더 파일이 누락된 것 같습니다. 위의 예제 sys/types.h는 아마도 C 표준 라이브러리로 분류될 수 없으나, Linux 운영체제에서 제공하는 SDK입니다. 따라서 OS SDK .h, C 표준 라이브러리, C++ 표준 라이브러리, 다른 라이브러리의 헤더 파일, 자신의 프로젝트 헤더 파일이 더 정확해야 한다고 생각합니다.

3. 헤더 파일이 위치한 프로젝트 디렉터리를 나열하는 이유는 실수로 중복된 파일 이름을 구별하기 위해 네임스페이스가 동일해야 하기 때문입니다.

2. "C++ 프로그래밍 생각"의 다양한 관점

"Google C++ 프로그래밍 스타일 가이드"와는 달리 "C++ 프로그래밍 생각"은 다른 규칙을 옹호합니다. "C++ 프로그래밍 사고" P432 언급:

헤더 파일이 포함되는 순서는 "가장 구체적인 것부터 가장 일반적인 것"입니다. 즉, 로컬 디렉터리의 모든 헤더 파일이 먼저 포함됩니다. 그런 다음 자체 "도구" 헤더, 타사 라이브러리 헤더, 표준 C++ 라이브러리 헤더 및 C 라이브러리 헤더가 차례로 옵니다.

이유를 이해하려면: John Lakos의 "Large Scale C++ Software Design"(참고: 중국어 번역은 "Large Scale C++ 프로그래밍")의 한 구절을 읽어보세요.

보증. h 파일의 구성 요소는 자체적으로 구문 분석되지 않으므로 잠재적인 사용 오류가 방지됩니다. 그 자체로 구문 분석되는 것에는 명시적으로 제공된 선언이나 정의가 부족하기 때문입니다. .c 파일의 첫 번째 줄에 .h 파일을 포함하면 구성 요소의 물리적 인터페이스에 중요한 모든 내부 정보 블록이 .h에 있음을 보장합니다(일부 정보 블록이 실제로 누락된 경우 .c 파일이 생성된 후 컴파일할 수 있음). 파일이 이 문제를 발견했습니다)입니다.

포함된 헤더 파일의 순서가 "가장 구체적인 것부터 가장 일반적인 것"인 경우 헤더 파일이 자체적으로 구문 분석되지 않는 경우입니다. 바로 찾아서 문제가 발생하지 않도록 하겠습니다.

3. 내 실험

어떤 포함 순서가 더 좋나요? 저는 VS 2005를 사용하여 여러 파일이 포함된 콘솔 테스트 프로젝트 TestInc를 컴파일했습니다.

MyMath.h의 코드는 다음과 같습니다.

#pragma once  
double acos(double Num);
MyMath.cpp的代码如下：
double acos(double Num)  
{  
    return 1.0;  
}

TestInc.cpp의 코드는 다음과 같습니다. :

#include "TestInc.h"  
#include <stdio.h>  
#include <math.h>  
  
int _tmain(int argc, _TCHAR* argv[])  
{  
    double a = acos(0.5);  
    return 0;  
}

결과는 오류였습니다:

1>c:program filesmicrosoft visualstudio 8vcincludemath.h(107) : error C2732: 链接规范与“acos”的早期规范冲突
1>       c:program filesmicrosoft visual studio 8vcincludemath.h(107) : 参见“acos”的声明

그런 다음 TestInc.cpp의 헤더 파일 포함 순서를 다음으로 변경했습니다:

#include <stdio.h>  
#include <math.h>  
#include "TestInc.h"

그리고 컴파일이 통과되었습니다. 디버깅 및 실행 시 메인 함수 호출은 여전히 ​​C 표준 라이브러리의 acos 함수인 것으로 보입니다. 함수 호출 순서는 헤더 파일 포함 순서에 따라 결정되는 것 같습니다. 즉, 내 사용자 정의 acos 함수를 덮어쓰는 것입니다( TestInc.h에 다음이 포함되어 있는 경우 함수가 연결되면 인라인 함수가 먼저 호출됩니다.

이 작은 실험을 통해 나는 다음과 같은 결론에 도달했습니다. "Google C++ 프로그래밍 스타일 가이드"와 "C++ 프로그래밍 생각"에서 주장하는 헤더 파일을 포함하는 순서는 각각 다릅니다. "Google C++ 프로그래밍 스타일 가이드"는 숨겨진 헤더 파일 종속성을 크게 줄일 수 있어야 하며 "C++ 프로그래밍 아이디어"는 정의한 인터페이스가 시스템 라이브러리 및 타사 라이브러리와 충돌하는지 여부를 쉽게 알려줍니다.

4. 헤더 파일 포함 시 사전 컴파일 기능

Visual Studio 환경에서 개발하면서 거의 모든 cpp 파일에 stdafx.h 파일이 포함되어야 하고, 그렇지 않으면 오류가 발생합니다. 왜 이런가요?

原来Visual Studio采用一种预编译的机制。要了解预编译机制，先介绍一下预编译头。所谓的预编译头就是把一个工程中的那一部分代码，预先编译好放在一个文件里（通常是以.pch为扩展名的），这个文件就称为预编译头文件这些预先编译好的代码可以是任何的C/C++代码，甚至是inline的函数，但是必须是稳定的，在工程开发的过程中不会被经常改变。如果这些代码被修改，则需要重新编译生成预编译头文件。注意生成预编译头文件是很耗时间的。同时你得注意预编译头文件通常很大，通常有6- 7M大。注意及时清理那些没有用的预编译头文件。

也许你会问：现在的编译器都有Time stamp的功能，编译器在编译整个工程的时候，它只会编译那些经过修改的文件，而不会去编译那些从上次编译过，到现在没有被修改过的文件。那么为什么还要预编译头文件呢？答案在这里，我们知道编译器是以文件为单位编译的，一个文件经过修改后，会重新编译整个文件，当然在这个文件里包含的所有头文件中的东西（.eg Macro, Preprocessor ）都要重新处理一遍。 VC的预编译头文件保存的正是这部分信息。以避免每次都要重新处理这些头文件。

根据上文介绍，预编译头文件的作用当然就是提高便宜速度了，有了它你没有必要每次都编译那些不需要经常改变的代码。编译性能当然就提高了。

要使用预编译头，我们必须指定一个头文件，这个头文件包含我们不会经常改变的代码和其他的头文件，然后我们用这个头文件来生成一个预编译头文件（.pch 文件）想必大家都知道StdAfx.h这个文件。很多人都认为这是VC提供的一个“系统级别”的，编译器带的一个头文件。其实不是的，这个文件可以是任何名字的。我们来考察一个典型的由AppWizard生成的MFC Dialog Based　程序的预编译头文件。（因为AppWizard会为我们指定好如何使用预编译头文件，默认的是StdAfx.h，这是VC起的名字）。我们会发现这个头文件里包含了以下的头文件：

#include <afxext.h> // MFC extensions  
#include <afxdisp.h> // MFC Automation classes  
#include <afxdtctl.h> // MFC support for Internet Explorer 4 Common Controls 
#include <afxcmn.h>

这些正是使用MFC的必须包含的头文件，当然我们不太可能在我们的工程中修改这些头文件的，所以说他们是稳定的。

那么我们如何指定它来生成预编译头文件。我们知道一个头文件是不能编译的。所以我们还需要一个cpp文件来生成.pch 文件。这个文件默认的就是StdAfx.cpp。在这个文件里只有一句代码就是：#include“Stdafx.h”。原因是理所当然的，我们仅仅是要它能够编译而已―――也就是说，要的只是它的.cpp的扩展名。我们可以用/Yc编译开关来指定StdAfx.cpp来生成一个.pch文件，通过/Fp 编译开关来指定生成的pch文件的名字。打开project ->Setting->C/C++ 对话框。把Category指向Precompiled Header。在左边的树形视图里选择整个工程，Project Options(右下角的那个白的地方)可以看到 /Fp “debug/PCH.pch”，这就是指定生成的.pch文件的名字，默认的通常是　.pch。然后，在左边的树形视图里选择 StdAfx.cpp，这时原来的Project Option变成了 Source File Option（原来是工程，现在是一个文件，当然变了）。在这里我们可以看到 /Yc开关，/Yc的作用就是指定这个文件来创建一个Pch文件。/Yc后面的文件名是那个包含了稳定代码的头文件，一个工程里只能有一个文件的可以有 YC开关。VC就根据这个选项把 StdAfx.cpp编译成一个Obj文件和一个PCH文件。

这样，我们就设置好了预编译头文件。也就是说，我们可以使用预编译头功能了。以下是注意事项：

1）如果使用了/Yu，就是说使用了预编译，我们在每个.cpp文件的最开头，包含你指定产生pch文件的.h文件（默认是stdafx.h）不然就会有问题。如果你没有包含这个文件，就告诉你Unexpected file end.

2）如果你把pch文件不小心丢了，根据以上的分析，你只要让编译器生成一个pch文件就可以了。也就是说把stdafx.cpp（即指定/Yc的那个cpp文件）重新编译一遍就可以了。

那么在Linux平台下有没有这种预编译机制呢？如果有，它是怎么实现的呢？Linux平台下GCC编译器也实现了预编译机制的。这里以开源IDE CodeBlocks（CodeBlocks内置了GCC编译器）的工程为例来说明Linux平台的实现：

使用CodeBlocks建一个C++工程，然后新建一个my_pch.h，输入如下代码：

/*************************************************************** 
 * Name:      my_pch.h 
 * Purpose:   Header to create Pre-Compiled Header (PCH) 
 * Author:     () 
 * Created:   2010-10-26 
 * Copyright:  () 
 * License: 
 * 使用方法: 项目构建选项-->其他选项-->填入下面两行 
 -Winvalid-pch 
 -include my_pch.h 
 **************************************************************/  
  
#ifndef MY_PCH_H_INCLUDED  
#define MY_PCH_H_INCLUDED  
  
// put here all your rarely-changing header files  
  
#include <iostream>  
#include <string>  
  
#endif

然后在项目构建选项–>其他选项–>填入下面两行

-Winvalid-pch
-include my_pch.h

就可以启用预编译文件头。

然后 main.cpp 就可以不用 include 头文件了，直接这样就可以编译了

int main()  
{   
using namespace std;  
    cout << "Hello world!" << endl;  
    return 0;  
}

即使在上面的代码写上下面一行，其实是不起作用的：

#include <iostream>

以上就是C++ 头文件的包含顺序研究的内容，更多相关内容请关注PHP中文网（www.php.cn）！