global scope variable in .cpp file?

[shaun]

If I put (define) const variables at the top of a .cpp file but do not
declare them in the .h file, are they only visible within that .cpp file?

e.g.

const int a[]={1,2,3,4};

in a cpp file will be a 'global' with file scope? (no flames for
oxymoron, please), available for use inside my functions which are
defined in the same file (but which are also declared in the .h)?

On trying it, this appears to be true, but then:
In this case, what does the 'static' keyword lend to the definition?
Schildts' book (C++ The complete reference) tells me that "Applying the
specifier static to a global variable instructs the compiler to create a
global variable that is known only to the file in which you declared it."

cheers

shaun

[Alf P. Steinbach]

* shaun:

If I put (define) const variables at the top of a .cpp file but do not
declare them in the .h file,
The files declarations are placed in do not matter. What matters is
only the sequence the compiler encounters the declarations in. The C++
standard does not rely on a notion of "file", and indeed your source
code does not need to reside in a file; e.g., if you're using the g++
compiler, try the command

g++ -x c++ -

and then just type in some C++ source code (how you indicate end of text
depends on the system, e.g. Unix [Ctrl D] or Windows [Ctrl Z] Return).

are they only visible within that .cpp file?

e.g.

const int a[]={1,2,3,4};
If there is no previous declaration of 'a' then 'a' has internal
linkage, which means it's not accessible by name outside the compilation
unit (in practical terms, it's invisible to the linker).

in a cpp file will be a 'global' with file scope? (no flames for
oxymoron, please), available for use inside my functions which are
defined in the same file (but which are also declared in the .h)?
Yes, in the sense explained above.

On trying it, this appears to be true, but then:
In this case, what does the 'static' keyword lend to the definition?
Schildts' book (C++ The complete reference) tells me that "Applying the
specifier static to a global variable instructs the compiler to create a
global variable that is known only to the file in which you declared it."

Look up what the [alt.comp.lang.l earn.c-c++] FAQ says about Schildt...

The C++ standard is not concerned with files (see example above).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[roberts.noah]

shaun wrote:

If I put (define) const variables at the top of a .cpp file but do not
declare them in the .h file, are they only visible within that .cpp file?

e.g.

const int a[]={1,2,3,4};

in a cpp file will be a 'global' with file scope? (no flames for
oxymoron, please), available for use inside my functions which are
defined in the same file (but which are also declared in the .h)?

That is a C thing only I believe. In C you can still access a variable
by name in another object file even if you don't have that name
declaired in the current object file. Using extern just gets rid of
warnings. Using static on a "global" in C creates a file scope
variable. In C++ I believe that any variable you don't have declaired
in your scope just plain isn't in your scope (where in C if there is no
static it is a *global*) so the static keyword serves no purpose in
such declarations in C++.

I could be wrong...I tend to refrain from using globals.

[roberts.noah]

ro**********@gm ail.com wrote:

shaun wrote:

If I put (define) const variables at the top of a .cpp file but do not
declare them in the .h file, are they only visible within that .cpp file?

e.g.

const int a[]={1,2,3,4};

in a cpp file will be a 'global' with file scope? (no flames for
oxymoron, please), available for use inside my functions which are
defined in the same file (but which are also declared in the .h)?

That is a C thing only I believe. In C you can still access a variable
by name in another object file even if you don't have that name
declaired in the current object file. Using extern just gets rid of
warnings. Using static on a "global" in C creates a file scope
variable. In C++ I believe that any variable you don't have declaired
in your scope just plain isn't in your scope (where in C if there is no
static it is a *global*) so the static keyword serves no purpose in
such declarations in C++.

I could be wrong...I tend to refrain from using globals.

And I am: http://david.tribble.com/text/cdiffs...static-linkage

[joseph.rajesh]

>If I put (define) const variables at the top of a .cpp file but do not

declare them in the .h file, are they only visible within that .cpp file?
e.g.
const int a[]={1,2,3,4};
In this case during compilation stage yes it is visible only to that
..cpp file. but during linking stage it is accessible by all the files.
Though in linking stage all the files are combined to form a single
executive.....

In this case, what does the 'static' keyword lend to the definition?
Schildts' book (C++ The complete reference) tells me that "Applying the
specifier static to a global variable instructs the compiler to create a
global variable that is known only to the file in which you declared it."

But making a variable static makes it visible only to that cpp only. It
cannot be accessed in other files by any means.

If you just declare a global variable e.g.
int value = 10;
you cannot create a global variable with the same name in any of your
files. This shows that in linking stage a global variable is visible to
all the files. but not a static variable.

[Gavin Deane]

jo***********@g mail.com wrote:

If I put (define) const variables at the top of a .cpp file but do not
declare them in the .h file, are they only visible within that .cpp file?
e.g.
const int a[]={1,2,3,4};

In this case during compilation stage yes it is visible only to that
.cpp file. but during linking stage it is accessible by all the files.
Though in linking stage all the files are combined to form a single
executive.....

Not if (as in the OP's case) the name is explicitly declared const.
File-scope const objects have internal linkage.

In this case, what does the 'static' keyword lend to the definition?
Schildts' book (C++ The complete reference) tells me that "Applying the
specifier static to a global variable instructs the compiler to create a
global variable that is known only to the file in which you declared it."

But making a variable static makes it visible only to that cpp only. It
cannot be accessed in other files by any means.

For a const object, static in this case adds nothing. Well, it adds to
the confusion of different meanings for the static keyword. Which is
why this use of static is deprecated.

Gavin Deane

[Alf P. Steinbach]

* jo***********@g mail.com:

If I put (define) const variables at the top of a .cpp file but do not
declare them in the .h file, are they only visible within that .cpp file?
e.g.
const int a[]={1,2,3,4};
In this case during compilation stage yes it is visible only to that
.cpp file. but during linking stage it is accessible by all the files.
Though in linking stage all the files are combined to form a single
executive.....

Sorry, that's incorrect: in C++ const variables default to internal
linkage.
[snip] But making a variable static makes it visible only to that cpp only. It
cannot be accessed in other files by any means.
First, C++ does not care about the physical organization of the program
text in files.

Second, a static variable can be accessed anywhere via a pointer or
reference.

It's only for access by name that there is a restriction, namely to the
translation unit (note: that's not the same as a file) it appears in.

If you just declare a global variable e.g.
int value = 10;
you cannot create a global variable with the same name in any of your
files.
Sorry, that's incorrect: avoiding such possible name clashes is what C++
namespaces are for.

This shows that in linking stage a global variable is visible to
all the files. but not a static variable.

When you write "global variable" here you probably mean a variable with
external linkage. Be aware that others use the same term, "global
variable", with other meanings. In particular, many find it perfectly
reasonable to call an internal linkage variable of namespace scope a
"global variable".

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?