It's the exact same reason why the C++ source files frequently sport
the ".cpp" extension.
The extension on the source file is used by the compiler, to
determine whether to compile the file as C++ or as C. The
extension on the include file is ignored by the compiler.
Of course, with all of the compilers I know, you can override
this. Historically, .cc seems to be the most frequent extension
for C++ sources in a Unix environment, but older versions of
VC++ didn't recognize it, so I regularly used the /Tp option
when I compiled; it was easier to add this in the makefile than
to rename all of my files. (Historically, of course, the
extension for C++ sources was .C, as opposed to .c for C
sources. This convention broke down as soon as C++ was ported
to OS's which didn't have case sensitive filenames, however.)
I've used those extensions, along with ".c++" and ".h++". I've
also seen projects which adopted the ".cxx" and ".hxx"
extensions.
The problem is precisely that the convention (established by the
creator of the language) was .C. When different people ported
to systems which didn't have case sensitive filenames, they had
to create a new convention. The most common to begin with seem
to have been .cc and .cxx, but Microsoft (and maybe Borland
before them) adopted .cpp, so that rapidly became the most
common under Windows. All three are acceptable to all modern
compilers I know.
For whatever reason, Stroustrup didn't distinguish between C and
C++ header files: .h was the convention for C, and it was also
the extention for the earliest C++ headers. Many people (myself
included) have felt that it would be better to distinguish, and
simply adopted the same convention as for source files,
replacing the c with an h: .H in the far distant past, then .hh
or .hxx, and finally .hpp under Windows. In the case of include
files, however, the compiler doesn't care. In the past, .ihh
was frequent (at least in the places I worked) for headers which
defined the inline functions (and which were included from
another header); along the same lines, I have long used .lhh (in
addition to .hh) for local headers, which were used when
compiling a component, but which weren't exported. And I've
also adopted a convention used by g++ (and others), using .tcc
for template sources (which I used to put in the .ihh files).
Another poster mentionned IDE's: my editors are configured so
that any filename matching *.*hh or *.*cc is treated as C++; *.h
and *.c are treated as C. And of course, it would be trivial to
change the configuration so that it recognized *.hpp and *.cpp
as well.
The important thing is to establish a convention, document it,
and to ensure that everyone knows it.
Pete Becker correctly pointed out that you shouldn't be using an
include file without having read its documentation. Curiously
enough, however, the documentation I've seen rarely mentions the
programming language, however---one assumes that everything in
Boost is C++, and everything in Posix is C, but I don't think
I've seen it documented. And while this is definitly a safe
(and obvious) assumption in those two cases, I'm not sure it's
that obvious for other libraries. And of course, you might want
other programs (e.g. the editor) to behave differently depending
on the language, and other programs don't read the
documentation.
To me, the single advantage is that just by looking at the
file name it is automatically possible to know that the code
it contains is C or C++. That is particularly useful if a
project handles both C and C++ modules.
I agree that it's useful, although you still don't know whether
the .h is C only, or C and C++.
On the other hand, there are quite a few artificial
disadvantages. There are quite a few IDEs and other software
that, although were written to handle C++ programming, do not
accept anything beyond the popular ".h" and ".cpp" extensions
or even breaking miserably if they stumble on some other
extension.
Are you kidding? I've never encountered one.
