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".

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

在Bjarne Stroustrup的《c++程序设计语言第三版》(第nº1本c++必读书籍)中，他使用了*.h。所以我认为最好的做法是使用*.h。

但是，*.hpp也很好!

我使用.hpp是因为我想让用户区分哪些头文件是c++头文件，哪些头文件是C头文件。

当你的项目同时使用C和c++模块时，这一点非常重要:就像其他人在我之前解释的那样，你应该非常小心地做这件事，它从你通过扩展提供的“契约”开始

.hpp: c++头文件

(或。hxx，或。hh，或其他)

此头文件仅适用于c++。

如果你在C模块，甚至不要尝试包含它。你不会喜欢它，因为没有努力使它对c友好(太多的东西会丢失，比如函数重载、名称空间等等)。

.h:兼容C/ c++或纯C头文件

C源代码和c++源代码都可以直接或间接地包含这个头文件。

它可以直接包含，由__cplusplus宏保护:

这意味着，从c++的观点来看，与C兼容的代码将被定义为extern“C”。 从C的角度来看，所有的C代码都是清晰可见的，但c++代码是隐藏的(因为它不会在C编译器中编译)。

例如:

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

   #ifdef __cplusplus
      } // extern "C"
   #endif

#endif // MY_HEADER_H

或者它可以通过相应的.hpp头以extern“C”声明间接包含。

例如:

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

extern "C"
{
#include "my_header.h"
}

#endif // MY_HEADER_HPP

and:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_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。

我更喜欢用.hpp作为c++头文件，这样可以让编辑器和其他程序员清楚地知道它是c++头文件，而不是C头文件。

下面是C和c++头文件命名不同的几个原因:

Automatic code formatting, you might have different guidelines for formatting C and C++ code. If the headers are separated by extension you can set your editor to apply the appropriate formatting automatically Naming, I've been on projects where there were libraries written in C and then wrappers had been implemented in C++. Since the headers usually had similar names, i.e. Feature.h vs Feature.hpp, they were easy to tell apart. Inclusion, maybe your project has more appropriate versions available written in C++ but you are using the C version (see above point). If headers are named after the language they are implemented in you can easily spot all the C-headers and check for C++ versions.

记住，C不是c++，除非你知道你在做什么，否则混合和匹配是非常危险的。适当地命名源代码可以帮助您区分语言。