Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > extern gloabal variable in .h Possible to use in .c withoutincluding .h

Reply
Thread Tools

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

 
 
knight
Guest
Posts: n/a
 
      02-15-2011
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 ?
 
Reply With Quote
 
 
 
 
Gerhard Fiedler
Guest
Posts: n/a
 
      02-15-2011
knight wrote:

> 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
 
Reply With Quote
 
 
 
 
Juha Nieminen
Guest
Posts: n/a
 
      02-16-2011
Gerhard Fiedler <(E-Mail Removed)> wrote:
> knight wrote:
>
>> 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.


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).
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-17-2011
On Feb 16, 3:39 pm, Juha Nieminen <(E-Mail Removed)> wrote:
> Gerhard Fiedler <(E-Mail Removed)> wrote:
> > knight wrote:


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


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

--
James Kanze
 
Reply With Quote
 
gwowen
Guest
Posts: n/a
 
      02-17-2011
On Feb 17, 9:44*am, James Kanze <(E-Mail Removed)> wrote:
> 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 {}"
 
Reply With Quote
 
Dilip
Guest
Posts: n/a
 
      02-17-2011
On Feb 17, 4:44*am, James Kanze <(E-Mail Removed)> wrote:
> On Feb 16, 3:39 pm, Juha Nieminen <(E-Mail Removed)> wrote:
>
> > Gerhard Fiedler <(E-Mail Removed)> wrote:
> > > knight wrote:
> > >> 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.

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


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


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.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      02-17-2011
James Kanze <(E-Mail Removed)> 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#).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Difference of extern short *x and extern short x[]? Andre C Programming 5 07-17-2012 07:38 PM
many aspnet applications in one site? many Gloabal.asax files ok? dee ASP .Net 2 08-15-2005 03:07 AM
where to find gloabal.asax in VS.NET 2005 sunnyz ASP .Net 0 10-17-2004 07:55 PM
extern const char * vs. extern const char []http://tinyurl.com/47e3k Thomas Matthews C++ 5 08-02-2004 10:36 AM
Vondafone GPRS Internet / Europe Gloabal Roaming Lonney NZ Computing 11 02-22-2004 03:54 AM



Advertisments