#include <<.<>
would be a valid includable header file name.
Even this would conform to C++, it would be a pretty pretty stupid idea, tho.
And that's why .hpp is valid, too.
But it's not an outcome of the committees designing decisions for the language!
So discussing about to use .hpp is same as doing it about .cc, .mm or what ever else I read in other posts on this topic.
I have to admit I have no clue where .hpp came from1, but I would bet an inventor of some parsing tool, IDE or something else concerned with C++ came to this idea to optimize some internal processes or just to invent some (probably even for them necessarily) new naming conventions.
But it is not part of the language.
And whenever one decides to use it this way. May it be because he likes it most or because some applications of the workflow require it, it never2 is a requirement of the language. So whoever says "the pp is because it is used with C++", simply is wrong in regards of the languages definition.
C++ allows anything respecting the previous paragraph.
And if there is anything the committee proposed to use, then it is using .h since this is the extension sued in all examples of the ISO document.
Conclusion:
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 or *.hpp for your class definitions" is:
Both are equally correct and applicable as long as no external restrictions are present.
1From what I know, apparently, it is the boost framework that came up with that .hpp extension.
2Of course I can't say what some future versions will bring with it!
I've recently started using *.hpp for c++ headers.
The reason is that I use emacs as my primary editor and it enters automatically into c-mode when you load a *.h file and into c++-mode when you load a *.hpp file.
Apart that fact I see no good reasons for choosing *.h over *.hpp or vice-versa.
–
You can call your includes whatever you like.
Just need to specify that full name in the #include.
I suggest that if you work with C to use .h and when with C++ to use .hpp.
It is in the end just a convention.
Codegear C++Builder uses .hpp for header files automagically generated from Delphi source files, and .h files for your "own" header files.
So, when I'm writing a C++ header file I always use .h.
Bjarne Stroustrup and Herb Sutter have a statement to this question in their C++ Core guidelines found on: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source which is also refering to the latest changes in the standard extension (C++11, C++14, etc.)
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.
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.
I'm not a big fan of this convention because if you are using a popular library like boost, your consistency is already broken and you should better use .hpp.
It is easy for tools and humans to differentiate something. That's it.
In conventional use (by boost, etc), .hpp is specifically C++ headers. On the other hand, .h is for non-C++-only headers (mainly C). To precisely detect the language of the content is generally hard since there are many non-trivial cases, so this difference often makes a ready-to-use tool easy to write. For humans, once get the convention, it is also easy to remember and easy to use.
However, I'd point out the convention itself does not always work, as expected.
It is not forced by the specification of languages, neither C nor C++. There exist many projects which do not follow the convention. Once you need to merge (to mix) them, it can be troublesome.
.hpp itself is not the only choice. Why not .hh or .hxx? (Though anyway, you usually need at least one conventional rule about filenames and paths.)
I personally use both .h and .hpp in my C++ projects. I don't follow the convention above because:
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.)
I usually use .hpp on C++ headers and the headers should be used (maintained) in a header-only manner, e.g. as template libraries. For other headers in .h, either there is a corresponding .cpp file as implementation, or it is a non-C++ header. The latter is trivial to differentiate through the contents of the header by humans (or by tools with explicit embedded metadata, if needed).
As many here have already mentioned, I also prefer using .hpp for header-only libraries that use template classes/functions. I prefer to use .h for header files accompanied by .cpp source files or shared or static libraries.
Most of the libraries I develop are template based and thus need to be header only, but when writing applications I tend to separate declaration from implementation and end up with .h and .cpp files
–
–
In "The C++ Programming Language, Third Edition by Bjarne Stroustrup", the nº1 must-read C++ book, he uses *.h. So I assume the best practice is to use *.h.
However, *.hpp is fine as well!
–
–
–
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.
That being said, being able to accurately make assumptions based on the extension is very useful, so it would be wise to use an easily-understandable set of rules for your header files. Personally, I prefer to do something like this:
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".
Considering this, the main advantage would come in consistently naming your headers in the same style, and making that style readily apparent to anyone examining your code. This way, anyone familiar with your usual coding style will be able to determine what you mean with any given extension with just a cursory glance.
The extension of the source file may have meaning to your build system, for example, you might have a rule in your makefile for .cpp or .c files, or your compiler (e.g. Microsoft cl.exe) might compile the file as C or C++ depending on the extension.
Because you have to provide the whole filename to the #include directive, the header file extension is irrelevant. You can include a .c file in another source file if you like, because it's just a textual include. Your compiler might have an option to dump the preprocessed output which will make this clear (Microsoft: /P to preprocess to file, /E to preprocess to stdout, /EP to omit #line directives, /C to retain comments)
You might choose to use .hpp for files that are only relevant to the C++ environment, i.e. they use features that won't compile in C.
