You're entirely correct about everything you said, yet you're practically making my point for me. Maybe the confusion is that I reference gcc specifically. gcc is an excellent implementation of what irritates me in a very minor way. In fact, writing this much about it makes it sound like a huge problem either for me or for C++.
There are four reasons for #include
<my_callback.h>
in C++ to be taken as C++. The first
is that C++ started as a pre-processor and the standard
headers ended with .h before the ISO and ANSI standards. The
second is a failure to
subsequently differentiate between C and C++ headers,
leading to widespread use of .h for C++
headers. The third is to retain compatibility with C, which
can be used to justify letting .h be either C or C++. The
fourth is that the standard C++ headers have no extension;
therefore, everything must be assumed to be C++.
If allowing .h to be C++ is to allow for compatibility with
C then the point is lost because of the details I described
in previous
posts.
If allowing .h to be C++ is to take into consideration
older C++ headers ending with .h, that's something that
could have been standardized along with everything else.
The more likely reason is that a large number of programmers
still use .h for C++ headers. You've already lost
compatibility with C to some extent because
one has to explicitly let the compiler know that C is being
used. At that, some parts of standard C will never compile
when #include
d into a C++ file no matter how
you try to do it.
It's not the behavior that irritates me; I know there are
"official reasons" for it. It's the fact that one file can
be C in one context and C++ in another under the same
compiler. You can even #include
"hello, this is kevin"
, and something isn't right
about that.
Lastly, I can't believe you picked this to dispute out of my entire original post, but you have indeed made your point.
Kevin Barry