What is the significance of a .h file?

I know that .h file is suppos开发者_StackOverflow社区ed to have:

• class declarations,
• function prototypes,
• and extern variables (for global variables)

But is there some significance of making it a .h file? I tried renaming my .h file to a .c file and it still works.

We can name our file to be anything, but we choose to name it as a .h file.

Am I correct?

While the exact naming is a convention, the difference between the treatment of header files and source files is not -- header files are not compiled into object files, but included in source files (collectively forming translation units). Moreover they may be included in multiple source files, so that multiple source files share the same definitions. The semantics of the files may be the same, but the compiler treats them differently, because of their usage.

As far as naming goes, personally I've seen at least these -- *.h, *.H (ugh), *.hpp, *.hxx, *.hh, *.inl (for normal headers, not just inlined code -- yuck). Usually accompanied by a matching object file extension.

Note that standard library headers don't have an extension -- e.g. string.

So it's all a matter of taste and conventions -- what you will #include, that will be included.

The use of .h to name header files is just a convention. You will also see (probably on Unix-like platforms):

• .hpp (the Boost library uses these)
• .hxx (looks like h++ with the + signs tilted - cute, huh?)
• .H (Unix is case sensitive so you can distinguish these from .h files)

Personally, I'd strongly advise sticking with .h. Particularly, don't use .H, or you will be in a world of pain if you ever need to port to case-insensitive file system.

It's just a convention - the "h" stands for "header". Like most conventions though, you would need to have a very good reason to contravene it.

The name of a file, as well as its extension, means absolutely nothing to compiler. You can name them h.main or anything else. Just remember to keep includes intact.

I thought it might be worthwhile to expand the previous answer for Visual Studio-like IDEs.

For simplicity you should use naming conventions that are recognized by your programming IDE. The most important rules it has are the ones that tell it what compiler to use for which files. For example, .c will be compiled as C code, .cpp as C++, .cs as C#, .rc by the resource compiler and so on.

Naming something .h, or anything else not covered by one of the standard compiler selection rules, prevents a file being compiled on its own, which is what you want for header files. If you had tried your test of renaming your header to .c in Visual Studio, it would have been compiled for you unless you explicitly excluded it from the build.

There may be other tools available in your IDE - for example, tools to generate class diagrams, do source code analysis etc., and these may also have file naming conventions that you should stay compatible with.

Our big development projects #include cc files from cc file for classes with hundreds of methods. I didn't agree with it, but there were reasons.

you compile and link your .h and .cpp to .obj. Then you give .h and .obj (your part) to your partner (your partner have no knowledge about the actual code), finally linker merge all the obj to a executable. .h is an well-known indicator to tell programmer that this file does not contain definition. we can use .xyz if the whole world accept it :-)

Moreover, when you have a makefile, its possible to say something like, compile all files ending in .c to object files, rather than specifying each separately. Now if you start naming you header files with .c extensions, then the make system may try to compile the header files into object files...

So to have separate *.h and *.c files keeps everything distinct and clear, not only for the programmer, but just as crucially for the make system, compiler and linker.