There is no advantage to any particular extension, other than that one may have a different meaning to you, the compiler, and/or your tools. header.h is a valid header. header.hpp is a valid header. header.hh is a valid header. header.hx is a valid header. h.header is a valid header. this.is.not.a.valid.header is a valid header in denial. ihjkflajfajfklaf is a valid header. As long as the name can be parsed properly by the compiler, and the file system supports it, it's a valid header, and the only advantage to its extension is what one reads into it.

话虽如此，能够基于扩展准确地做出假设是非常有用的，因此对于头文件使用一组易于理解的规则将是明智的。就我个人而言，我更喜欢这样做:

If there are already any established guidelines, follow them to prevent confusion. If all source files in the project are for the same language, use .h. There's no ambiguity. If some headers are compatible with multiple languages, while others are only compatible with a single language, extensions are based on the most restrictive language that a header is compatible with. A header compatible with C, or with both C & C++, gets .h, while a header compatible with C++ but not C gets .hpp or .hh or something of the sort.

This, of course, is but one of many ways to handle extensions, and you can't necessarily trust your first impression even if things seem straightforward. For example, I've seen mention of using .h for normal headers, and .tpp for headers that only contain definitions for templated class member functions, with .h files that define templated classes including the .tpp files that define their member functions (instead of the .h header directly containing both the function declaration and the definition). For another example, a good many people always reflect the header's language in its extension, even when there's no chance of ambiguity; to them, .h is always a C header and .hpp (or .hh, or .hxx, etc.) is always a C++ header. And yet again, some people use .h for "header associated with a source file" and .hpp for "header with all functions defined inline".

考虑到这一点，主要的优势在于始终以相同的风格命名你的头文件，并使这种风格对任何检查你的代码的人来说都很明显。这样，任何熟悉您通常的编码风格的人都可以粗略地看一下，就可以确定您对任何给定扩展的意思。

在我90年代早期的一份工作中，我们分别使用.cc和.hh作为源文件和头文件。在所有的选择中，我仍然更喜欢它，可能是因为它最容易打字。

正如这里许多人已经提到的，我也更喜欢使用.hpp来处理使用模板类/函数的纯头文件库。我更喜欢使用.h作为头文件，附带.cpp源文件或共享或静态库。

我开发的大多数库都是基于模板的，因此只需要头文件，但在编写应用程序时，我倾向于将声明与实现分开，最终使用.h和.cpp文件

Codegear c++ Builder使用.hpp作为从Delphi源文件自动生成的头文件，使用.h文件作为“自己的”头文件。

所以，当我写一个c++头文件时，我总是使用.h。

Bjarne Stroustrup和Herb Sutter在他们的c++核心指南(https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source)中对这个问题有一个声明，该指南也提到了标准扩展(c++ 11, c++ 14等)的最新变化。

SF.1: Use a .cpp suffix for code files and .h for interface files if your Y project doesn't already follow another convention Reason It's a longstanding convention. But consistency is more important, so if your project uses something else, follow that. Note This convention reflects a common use pattern: Headers are more often shared with C to compile as both C++ and C, which typically uses .h, and it's easier to name all headers .h instead of having different extensions for just those headers that are intended to be shared with C. On the other hand, implementation files are rarely shared with C and so should typically be distinguished from .c files, so it's normally best to name all C++ implementation files something else (such as .cpp). The specific names .h and .cpp are not required (just recommended as a default) and other names are in widespread use. Examples are .hh, .C, and .cxx. Use such names equivalently. In this document, we refer to .h and .cpp > as a shorthand for header and implementation files, even though the actual extension may be different. Your IDE (if you use one) may have strong opinions about suffices.

我不是这种惯例的大粉丝，因为如果你正在使用像boost这样的流行库，你的一致性已经被打破了，你最好使用.hpp。

工具和人类很容易区分事物。就是这样。

在常规使用中(通过boost等)，.hpp是特别的c++头文件。另一方面，.h用于非c++专用的头文件(主要是C)。由于存在许多非平凡的情况，因此精确检测内容的语言通常很难，因此这种差异通常使现成的工具易于编写。对于人类来说，一旦习惯了，也就容易记忆和使用了。

然而，我要指出，公约本身并不总是如预期的那样有效。

它不受语言规范的强迫，无论是C还是c++。有许多项目不遵循惯例。一旦你需要合并(混合)它们，就会很麻烦。 .hpp本身不是唯一的选择。为什么不是。hh或。hxx?(尽管无论如何，您通常至少需要一个关于文件名和路径的常规规则。)

我个人在我的c++项目中使用。h和。hpp。我没有遵循上面的惯例，因为:

The languages used by each part of the projects are explicitly documented. No chance to mix C and C++ in same module (directory). Every 3rdparty library is required to conforming to this rule. The conformed language specifications and allowed language dialects used by the projects are also documented. (In fact, I even document the source of the standard features and bug fix (on the language standard) being used.) This is somewhat more important than distinguishing the used languages since it is too error-prone and the cost of test (e.g. compiler compatibility) may be significant (complicated and time-consuming), especially in a project which is already in almost pure C++. Filenames are too weak to handle this. Even for the same C++ dialect, there may be more important properties suitable to the difference. For example, see the convention below. Filenames are essentially pieces of fragile metadata. The violation of convention is not so easy to detect. To be stable dealing the content, a tool should eventually not only depend on names. The difference between extensions is only a hint. Tools using it should also not be expected behave same all the time, e.g. language-detecting of .h files on github.com. (There may be something in comments like shebang for these source files to be better metadata, but it is even not conventional like filenames, so also not reliable in general.)

我通常在c++的头文件中使用.hpp，并且头文件应该只以头文件的方式使用(维护)，例如作为模板库。对于.h中的其他头文件，要么有相应的.cpp文件作为实现，要么是非c++头文件。后者对于人工(或具有显式嵌入元数据的工具，如果需要的话)通过头的内容进行区分是微不足道的。