我的类定义一直使用*.h文件,但在阅读了一些boost库代码后,我意识到它们都使用*.hpp。我一直很讨厌这个文件扩展名,我想主要是因为我不习惯它。

使用*.hpp而不是*.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。

其他回答

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。

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

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

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

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

你可以选择对那些只与c++环境相关的文件使用.hpp,也就是说,它们使用的特性不能用C编译。

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

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

你可以随意命名你的include。

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

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

它最终只是一种惯例。