Re: extern gloabal variable in .h Possible to use in .c without including .h
James Kanze <james.kanze@gmail.com> wrote:
Technically it would be possible to have the compiler automatically
deduce the declarations of externs from source files or object files
so that header files would not be needed for that purpose. (For example
C# does that.) There would be many obvious benefits from this,
Benefits? I see nothing but disadvantages, at least for larger
projects. The fact that you don't have headers (or something
which better solves the problem of keeping interface and
implementation separate) is a major drawback of Java (and
presumably C#).
The major problem with C/C++ header files is that they are source code.
(Moreover, they are actually source code for two "compilers": The
preprocessor and the actual C/C++ compiler.) This causes potential for
header files written by others to mess up your code. Strict coding
conventions have to be followed when writing header files to minimize this
danger. It wouldn't be the first time that the header file of some poorly
written library messes up someone's code (for example with careless
preprocessor macros or naming conventions) who is trying to use it.
(For example, nothing is more irritating than using, for example,
the name 'NO_ERROR' in your own code, and have your code not compile
with some C++ compiler where that exact name is a preprocessor macro in
some system header file. Yes, this is a concrete example that has happened
to me. I have heard of even worse horror stories.)
Of course there are clear advantages in being able to include source
code (mostly related to efficiency, especially when we are talking about
templated code which, by the fact of being included directly in the code
where they are used, allows the compiler to perform maximum optimizations
based on the usage context). However, including code for the sole reason
of declaring symbols is unnecessary and causes potential problems. There
are much better mechanisms for declaring symbols than including source
code.
There are also potential maintenance issues. If symbol declarations and
implementations are in one single file (eg. an object file or a statically
or dynamically loadable precompiled library), it makes sure that the
symbol declarations always match the implementations. With separate header
files there is the possibility that the header files do not match the
implementations, causing potential problems. The more complex the project,
the higher the risk of this happening. This is not a problem that "we just
have to live with" because it has been solved with other programming
languages.
I'm not saying that being able to #include code doesn't have its
advantages. I'm saying that having to do so in order to declare symbols is
unnecessary and only causes potential problems, and that this particular
issue has been done better in other languages (such as C#).