问题
I would like to know why we use ".hh" as extension for C++ header files instead of using just ".h".
The header files are preprocessed and the preprocessor doesn't even care about the extension of the header file. So, even if I create a header file with an extension ".qwe" (test.qwe). Then, why to use ".hh" as extension for C++ header files.
Some say, we are using ".cc" as extension for C++ files to differentiate from C files (which has an extension ".c"), likewise we are using using ".hh" as extension for C++ header files to differentiate from C header files (which has an extension ".h"). I don't think this to be a valid reason.
Does anyone know the reason for naming in such a way?
回答1:
Some say, we are using ".cc" as extension for C++ files to differentiate from C files (which has an extension ".c"), likewise we are using using ".hh" as extension for C++ header files to differentiate from C header files (which has an extension ".h").
That is exactly the reason. It is just to differentiate CPP headers from C headers.
Some programmers and libraries, such as Boost, use .hpp for CPP headers. My personal choice is this:
- example.c
- example.cpp
- example.h
- example.h++
Even if they all belong to a huge project, you can still figure out which one is which. No description is needed.
回答2:
You can name your headers as you wish, they can even have no extension at all.
This FAQ mentions header naming conventions.
回答3:
It's not for any specific reason, it's just a (developer- or project-specific) convention. As "file extension" is just part of name, it doesn't matter much, as source files are just plain text files. Furthermore, header files are just copy-pasted into file that included them (via #include, so file extension mean even less for them.
Borland's libraries' headers had .hpp extension. C++'s standard library headers have no extension at all. It's just a matter of convention and personal taste.
回答4:
One reason, if I'm creating a dll that has a C API around a bunch of C++ code, I need to differentiate between my C headers which the client may use to import C functions and my internal C++ headers which I explicitly don't want to allow the client to import.
Binding to a C function is pretty simple from most languages/environments with almost no overhead. You don't have to think about all the complexities inherit in C++. So if I were to work with such a library, I'd be sure to separate my C++ from my C interface.
回答5:
I think it is mostly a social convention.
However, recent GCC compilers are able to compile a (single) header foo.hh or foo.h into something like foo.hh.gch or foo.h.gch which essentially contains a persistent memory heap image of the compiler (the cc1plus program started by g++) after it had parsed that header.
Notice that the C++11 standard library defines header files like e.g. <vector> without any extension.
回答6:
This is completely convention, there is no special reason for it. Usually people try to stay consistent across a project, or across teams or even an entire company. It helps developers who pick up your code after you're long gone understand that you abc.hh goes with file abc.cc and abc.h goes with abc.c.
来源：https://stackoverflow.com/questions/10354321/c-reason-why-using-hh-as-extension-for-c-header-files