static keyword

1.

Is there any reason / benefit to modifying a file scope variable (declared outside of any function, block, or class -- i.e. a global variable) with the static keyword? For example:

static const int a = 123; // file scope

rather than just:

const int a = 123; // file scope

It appears that the static keyword changes nothing. Is this correct?

2.

The following two bolded sentences appear to be contradictory:

http://msdn2.microsoft.com/en-us/library/xfx9kcae.aspx
"A name specified using the static keyword has internal linkage except for the static members of a class that have external linkage. That is, it is not visible outside the current translation unit."

http://msdn2.microsoft.com/en-us/library/s1sb61xd.aspx
"When modifying a variable or function at file scope, the static keyword specifies that the variable or function has internal linkage (its name is not visible from outside the file in which it is declared)."

Any thoughts to clear this up? Testing shows the first is correct. And I would guess it is correct based on the thought: Exactly how could a variable not be visible outside of its own file, if this file were included into another? Is the second statement incorrect, or does it have meaning that I am unaware of?

Yes. The singleton class is a perfect reason. If you declare a class as a static class and declare the variable in the global scope as a static instance, you signify that the class is a single instance using static member variables and visable to all of the modules in your project on a global scope.

One possible class would be an environment class.

HTH,

To me both the statements sound about the same. The translation unit is in most cases equivalent to a file under compilation, so I understand. There may be subtle differences, but many people use the terms interchangeably.

The statement that a static varaible (defined at file level) is visible only in the file that it is declared in is true. Even if you include the file in multiple places, you will get multiple copies of the static variable, which means each would be a distinct variable. As you can imagine that is very different from a global variable that is visible across translation units.

Quote:

---

The following two bolded sentences appear to be contradictory:

---

No, they are not contradictory, they say the same. Notice that a translation unit is a source file that the compiler translates in an object file.

Quote:

---

Originally Posted by cilu

Notice that a translation unit is a source file that the compiler translates in an object file.

---

http://msdn2.microsoft.com/en-us/library/bxss3ska.aspx
"A source file, together with its include files (files that are included using the #include preprocessor directive) but not including sections of code removed by conditional-compilation directives such as #if, is called a "translation unit.""

This appears to contradict what you've said, and is the reason the two quotes in my original post appears contradictory.

Quote:

---

Originally Posted by JasonD

This appears to contradict what you've said, and is the reason the two quotes in my original post appears contradictory.

---

Sorry, I still don't see the contradiction. The #included header files are treated as if their content were actually part of the source (.cpp) file - the translation unit. Note that variables are normally never declared in header files.

Regarding your original question: The static keyword, applied to global variables, prevents the variable from being be visible to the linker, and hence avoids name clashes between global variables with the same name, but declared in different translation units (read: source files) when the object files resulting from compilation are later linked together to a library or executable.

Quote:

---

Originally Posted by JasonD

http://msdn2.microsoft.com/en-us/library/bxss3ska.aspx
"A source file, together with its include files (files that are included using the #include preprocessor directive) but not including sections of code removed by conditional-compilation directives such as #if, is called a "translation unit.""

This appears to contradict what you've said, and is the reason the two quotes in my original post appears contradictory.

---

There is no contradiction, because the #include are expanded during the pre-processor phase of translation. All that is in headers included in a source file end up being part of the source file.

http://msdn2.microsoft.com/en-us/lib...ka(vs.85).aspx

Quote:

---

Originally Posted by UnderDog

To me both the statements sound about the same. The translation unit is in most cases equivalent to a file under compilation, so I understand. There may be subtle differences, but many people use the terms interchangeably.

---

Quote:

---

Originally Posted by gstercken

Sorry, I still don't see the contradiction. The #included header files are treated as if their content were actually part of the source (.cpp) file - the translation unit.

---

Quote:

---

Originally Posted by cilu

There is no contradiction, because the #include are expanded during the pre-processor phase of translation. All that is in headers included in a source file end up being part of the source file.
http://msdn2.microsoft.com/en-us/lib...ka(vs.85).aspx

---

Thanks for all of your replies. I was aware of the phases of translation, but thanks for the explanation none-the-less. Allow me to clear up the confusion:

You guys, and the MSDN docs, say:
"file" = "translation unit" = [.cpp file + #included .h files]

And, silly me, was thinking:
"file" = [a single .cpp or .h file] != [.cpp file + #included .h files]

:rolleyes: (If the docs mean the 'translation unit', it should simply say 'translation unit'. 'file' is rather misleading, don't you think? Ignore your experience, and imagine a newcomer, and it becomes obvious.)

Ok, #2 solved. Thanks! :) Ok, let me read over your replies to issue #1.

Quote:

---

Originally Posted by cilu

http://msdn2.microsoft.com/en-us/lib...ka(vs.85).aspx

---

Heh. That's the same link in my post, that your post replied to!

Now that I am no longer confused between "file" and "translation unit", as MSDN uses them interchangeably, "static" all of a sudden makes complete sense to me for file scope variables...

Looking at my source files, I find that I use "static const" a lot for file scope variables. "const" implies (for C++, not C) that the variable has internal linkage, allowing "const" variables to be defined in .h files (whereas this is not possible in C, as they have external linkage). Therefore, I have one final question:

Adding "static" to a "const" file scope variable seems to have no effect in C++, since "const" in C++ already gives it internal linkage. Is this correct? Or am I missing something else that "static" may add?

Thanks for all of your replies.