使用哪个扩展名并不重要。两种都可以。

我用*.h表示C，用*.hpp表示c++。

你可以随意命名你的include。

只需要在#include中指定全名。

我建议你使用C语言时使用.h，使用c++时使用.hpp。

它最终只是一种惯例。

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

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

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

我最近开始在c++头文件中使用*.hpp。

原因是我使用emacs作为我的主编辑器，当你加载一个*.h文件时，它会自动进入c模式，当你加载一个*.hpp文件时，它会自动进入c++模式。

除此之外，我没有看到选择*.h而不是*.hpp或相反的理由。

源文件的扩展名可能对您的构建系统有意义，例如，您可能在makefile中有一个用于.cpp或. C文件的规则，或者您的编译器(例如Microsoft cl.exe)可能根据扩展名将文件编译为C或c++。

因为您必须向#include指令提供整个文件名，所以头文件扩展名是不相关的。如果您愿意，您可以在另一个源文件中包含.c文件，因为它只是一个文本包含。你的编译器可能有一个选项来转储预处理输出，这将使这一点明确(微软:/P预处理到文件，/E预处理到stdout， /EP省略#line指令，/C保留注释)

你可以选择对那些只与c++环境相关的文件使用.hpp，也就是说，它们使用的特性不能用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++，除非你知道你在做什么，否则混合和匹配是非常危险的。适当地命名源代码可以帮助您区分语言。

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

我使用。h，因为这是微软使用的，也是他们的代码生成器创建的。没必要违背常理。

我一直认为.hpp头文件是.h和.cpp文件的混合…还包含实现细节的标头。

通常，当我看到(并使用).hpp作为扩展名时，没有相应的.cpp文件。正如其他人所说，这不是一个严格的规则，只是我倾向于使用.hpp文件。

c++ ("C Plus Plus")作为.cpp是有意义的

扩展名为.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的《c++程序设计语言第三版》(第nº1本c++必读书籍)中，他使用了*.h。所以我认为最好的做法是使用*.h。

但是，*.hpp也很好!

编辑[增加了Dan Nissenbaum的建议]:

根据约定，当原型在头文件中定义时，使用.hpp文件。对于模板，头文件中的这种定义很有用，因为编译器只在模板实例化时为每种类型生成代码。因此，如果它们没有在头文件中定义，它们的定义将不会在链接时从其他编译单元解析。如果你的项目只使用c++，并且大量使用模板，这个约定将会很有用。

某些遵循此约定的模板库提供带有.hpp扩展名的头文件，以表明它们没有相应的.cpp文件。

另一个习惯是用.h表示C头文件，用.hpp表示c++头文件;boost库就是一个很好的例子。

引用自Boost FAQ， 文件扩展名向人类传递文件的“类型” 还有计算机程序。'.h'扩展名用于C头文件 文件，因此传达了关于c++头文件的错误信息 文件。不使用扩展不能传达任何信息，还会迫使检查 确定文件内容的类型。明确使用“。hpp” 将其标识为c++头文件，并且在实际应用中工作良好。 (Rainer Deyke)

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

在常规使用中(通过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++头文件。后者对于人工(或具有显式嵌入元数据的工具，如果需要的话)通过头的内容进行区分是微不足道的。

我回答这个问题是作为一个提醒，以指出我对“user1949346”回答这个OP的评论。

---

正如许多人已经回答的那样:两种方式都可以。 接着强调他们自己的印象。

介绍一下，正如前面提到的，我的观点是，如果没有反对的理由，c++头扩展名应该是。h。

由于ISO/IEC文档使用这种头文件的符号，甚至在他们的c++语言文档中也没有与.hpp匹配的字符串。

但我现在的目标是一个可认可的理由，为什么两种方式都是可以的，特别是为什么它不是语言本身的主题。

我们开始吧。

c++文档(我实际上参考了N3690版本)定义了头文件必须符合以下语法:

2.9报头名称 头名称: < h-char-sequence > “q-char序列” h-char-sequence: h-char h-char-sequence h-char h-char: 源字符集的任何成员，除了new-line和> q-char-sequence: q-char q-char-sequence q-char q-char: 源字符集的任何成员，除了new-line和"

因此，正如我们可以从这一部分提取的那样，头文件名也可以是源代码中任何有效的名称。除了包含'\n'字符并且取决于它是否包含<>，它不允许包含>。 或者另一种方式，如果包含了""-include则不允许包含"。

换句话说:如果您有一个环境支持像prettstupididea这样的文件名。>，一个include like:

#include "prettyStupidIdea.>"

是有效的，但是:

#include <prettyStupidIdea.>>

是无效的。反过来也一样。

甚至

#include <<.<>

将是一个有效的可包含头文件名。

即使这是符合c++的，但这将是一个非常非常愚蠢的想法。

这就是为什么.hpp也是有效的。

但这不是委员会为语言设计决策的结果!

所以讨论使用。hpp和讨论。cc，。mm或其他我在其他文章中读到的关于这个主题的东西是一样的。

我不得不承认，我不知道.hpp从何而来1，但我敢打赌，某些解析工具、IDE或其他与c++有关的东西的发明者想到这个想法是为了优化一些内部进程，或者只是为了发明一些(甚至可能是必要的)新的命名约定。

但它不是语言的一部分。

无论何时有人决定这样使用它。也许是因为他最喜欢它，或者是因为工作流的一些应用程序需要它，它从来不是语言的要求。因此，无论谁说“pp是因为它与c++一起使用”，就语言定义而言都是错误的。

c++允许与前一段有关的任何内容。 如果有什么是委员会建议使用的，那么它将使用.h，因为这是ISO文档中所有示例中使用的扩展名。

结论:

As long you don't see/feel any need of using .h over .hpp or vise versa, you shouldn't bother. Because both would be form a valid header name of same quality in respect to the standard. And therefore anything that REQUIRES you to use .h or .hpp is an additional restriction of the standard which could even be contradicting with other additional restrictions not conform with each other. But as OP doesn't mention any additional language restriction, this is the only correct and approvable answer to the question

“*.h或*.hpp用于类定义”是:

只要不存在外部限制，两者都是正确的和适用的。

---

1据我所知，显然是boost框架提供了.hpp扩展名。

当然我不能说未来的版本会带来什么!

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和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来处理使用模板类/函数的纯头文件库。我更喜欢使用.h作为头文件，附带.cpp源文件或共享或静态库。

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

幸运的是，这很简单。

如果您使用c++，您应该使用.hpp扩展名，并且您应该使用.h表示C或混合使用C和c++。