extern gloabal variable in .h Possible to use in .c withoutincluding .h

[knight]

An extern global variable is declared in header (.h) file . Is it
necessary to include the .h in a source c file to define it ?
If it is yes then why we include .h file?
Can this global variable be accessible in other source files without
including .h files ?

 

[Gerhard Fiedler]

An extern global variable is declared in header (.h) file .

Is it necessary to include the .h in a source c file to define it ?

No, but it is good practice.

If it is yes then why we include .h file?

It makes sure that the definition matches the declaration.

Can this global variable be accessible in other source files without
including .h files ?

Yes, if you add the extern declaration to the file. But to make sure the
declaration used in the other source files matches the definition, it is
good practice to include the header file (with the declaration that is
confirmed to match the definition by including it also in the source
file with the definition).

Gerhard

 

[Juha Nieminen]

No, but it is good practice.


It makes sure that the definition matches the declaration.

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, but it
would require some changes in the C++ syntax and compilers (basically,
a way to say "this name is global" in a source file).

 

[James Kanze]

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#).

but it
would require some changes in the C++ syntax and compilers (basically,
a way to say "this name is global" in a source file).

How about the way it's done now: the linkage of a symbol is
already determined by its definition.

 

[gwowen]

How about the way it's done now: the linkage of a symbol is
already determined by its definition.

It'd be nice to reverse the default, though.

i.e.

int globalvar;
static int localvar;
namespace {
int invisiblevar;
}

becomes

_global int globalvar;
/// alternatively
namespace _global
{
int globalvar;
}
int localvar;
int invisiblevar;

Failing that, a compiler switch that says "use local linkage for any
variable definition in a TU that does not have a matching 'extern'
declaration in the same TU".

// filed under "namespace pipedream {}"

 

[Dilip]

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#).

C# applications are never distributed in source form. C++ needs to
distribute a header for consuming applications to use the API and in
such cases separating the interface from the implementation is a great
idea. These two approaches aren't comparable. Besides if you write
distributed applications (what used to be called Remoting when .NET
first came out), one can still write the interface, compile it into an
assembly (.dll) and ship it off to the client. The infrastructure
usually takes care of remoting calls made on the interface to its
actual object implementation.

How about the way it's done now: the linkage of a symbol is
already determined by its definition.

I like gwowen's idea a lot better. I keep reading Stroustrup's
linkage chapter almost every day and I still never remember what kind
of definition has what kind of linkage specifier implicitly attached
to it.

 

[Juha Nieminen]

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#).