How can a translation unit access the global scope of another translation unit?

I have been reading about how linkers work and everything that comes around this process in order to explain my problem in this(link) question (it's short, sorry about the reference,but it's relevant).

The question: If in a header I have a variable declaration (using extern), and I want to use this variable in multiple source files (#including the header file in each one of them course), I have to provide a definition for this variable somewhere. The problem is that if I provide a definition in the main function of some of the source files for example, the other files still don't "see" this definition (which results in a linking error). If I define this extern variable in one of the global scopes, it works ok, and everybody sees it.

Why? How can other files access the global scope of another file? And aren't global scope variables dangerous? Placing the variable definition in what other scope can resolve such a linking error? Does somebody use such extern variable declarations in headers and for what purpose?

Edit: The exact example situation is in the link I have posted in the beginning


A few clarifications:

What you're calling a "file" is more properly called a translation unit. It doesn't matter how many files are involved. Indeed, the same file could be re-compiled (say with different #defines, etc.)

Armed with that term, we can now rephrase your question: "How can a translation unit access the global scope of another translation unit"?

Quoting from the wikipedia article on Linkage:

If the name has external linkage, the entity that name denotes may be referred to from another translation unit using a distinct declaration for that same name, and from other scopes within the same translation unit using distinct declarations.

In other words: by making sure that name as external linkage, it's in the global scope, and that's global for the program, not the translation unit.

Your remaining questions:

  1. Aren't global scope variables dangerous?

    I would never use the word "dangerous" to describe them, as I would certain standard library functions that have security flaws, etc. But I would say that can very often lead to very poorly designed code, and in the case of global variables specifically, a lot of headaches in multithreaded code. A good rule: avoid them unless you have a good reason not to.

  2. How to avoid the linkage error (in some other scope)

    No other magic declaration here: it's either visible outside the translation unit (external) or not (static). What you're probably asking for is : "What's the right way to let other modules access the variable?" And the answer is: write an accessor function (or even better, a class that manages that data with methods).

  3. Who uses this stuff and for what purpose?

    Always a hotly debated topic. Many people advise avoiding completely, but you'd be hard pressed not to find an extern in a project of sufficient size. The best reasons usually come down to the kind of things purists ignore: compatibility with legacy systems, performance, easy access for debuggers and other introspecting tools… or, of course, just cause it was easy, it was understood, and it just worked.

Need Your Help

Rendering an html string to view

c# jquery json

I have two controller actions that target the same view. That is, I have specified a view name on the call to View from controller action. The second action puts an html string in a ViewBag. I si...

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.