*.h or *.hpp for your class definitions

Question

I've always used a *.h file for my class definitions, but after reading some boost library code, I realised they all use *.hpp. I've always had an aversion to that file extension, I think mainly because I'm not used to it.

What do you use and why?

Edit: I realise both are ok, I'm just talking about personal preference.

Answer 1

It does not matte which on you use. Either one is Ok.

I use *.h for C and *.hpp for C++

Answer 2

just be glad they don't use *.hxx or extension-less headers!

*.h works for me, not that I'm too fussed either way.

Answer 3

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.

Answer 4

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.

Answer 5

In one of my jobs in the early 90's, we used .cc and .hh for source and header files respectively. I still prefer it over all the alternatives, probably because it's easiest to type.

Answer 6

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.

Answer 7

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.

Answer 8

Here are a couple of reasons for having different naming of C vs C++ headers:

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

Remember, C is not C++ and it can be very dangerous to mix and match unless you know what you are doing. Naming your sources appropriately helps you tell the languages apart.

Answer 9

I prefer .hpp for C++ to make it clear to both editors and to other programmers that it is a C++ header rather than a C header file.

Answer 10

I use .h because that's what Microsoft uses, and what their code generator creates. No need to go against the grain.

Answer 11

I always considered the .hpp header to be a sort of portmanteau of .h and .cpp files...a header which contains implementation details as well. Typically when I've seen (and use) .hpp as an extension, there is no corresponding .cpp file. As others have said, this isn't a hard and fast rule, just how I tend to use .hpp files.

Answer 12

C++ ("C Plus Plus") makes sense as .cpp

Having header files with a .hpp extension doesn't have the same logical flow.

Answer 13

I use .hpp because I want the user to differenciate what headers are C++ headers, and what headers are C headers.

This can be important when your project is using both C and C++ modules: Like someone else explained before me, you should do it very carefully, and its starts by the "contract" you offer through the extension

.hpp : C++ Headers

(Or .hxx, or .hh, or whatever)

This header is for C++ only.

If you're in a C module, don't even try to include it. You won't like it, because no effort is done to make it C-friendly (too much would be lost, like function overloading, namespaces, etc. etc.).

.h : C/C++ compatible or pure C Headers

This header can be included by both a C source, and a C++ source, directly or indirectly.

It can included directly, being protected by the __cplusplus macro:

• Which mean that, from a C++ viewpoint, the C-compatible code will be defined as extern "c".
• From a C viewpoint, all the C code will be plainly visible, but the C++ code will be hidden (because it won't compile in a C compiler).

For example:

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cpluplus
      extern "C"
      {
   #endif

   void myCFunction() ;

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

#endif // MY_HEADER_H

Or it could be included indirectly by the corresponding .hpp header enclosing it with the extern "c" declaration.

For example:

#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