C Globals – Are File-Scope Static Variables as Bad as Extern Global Variables?

cglobals

In C, you'd often/sometimes (as a matter of style) use a file-scope static variable where you'd use a private class member variable in C++. When scaling to multithreaded programs, simply adding thread_local in C11 or the long-supported extension __thread fits well. I know you can do exactly the same in C as C++ by putting everything inside a struct and making a set of functions that takes a pointer to that struct as its first argument. Some libraries do this extensively. But my personal style is to keep a struct as small as possible, if needed.

I often read or hear some people arguing 'global' variables are so much bad. I follow their reasons, and most of their argument seems to be related to extern global variables in C terms. What they say is certainly true. I sometimes use 1 or 2 of extern declared variables throughout the whole program when it'll simplify things a lot and when it's easy to keep track of them, but going further will easily make a program unpredictable.

What about static variables? Do they still have the same problem as 'real' global variables? Maybe I don't even have to ask this question and go on if I think what I'm doing is right, but today I saw another 'global variables are BAD' kind of post, and finally came here thinking perhaps this is a right place for such kind of question. What is your thought?

This question is not a duplicate of this because this question asks about extern and static non-local variables while the other question is about file-scope and block-scope static variables.

Best Answer

In a well-design C program, a file-static variable is similar to a private static member of a class:

It can only be accessed by functions in that file, similar to how a private static member variable can only be accessed by functions in the class in which it is defined.
There is only one copy of the variable.
Its lifetime is the program lifetime.

An extern variable would be a true global variable as in any language that supports them.

A static non-global variable is not as bad as a global; in fact, they are necessary in some cases.

Access is controlled through functions you write. This helps with data integrity including both bounds checking as well as thread-safety. (note: this does not guarantee thread-safety, it is simply one tool to help along the way)
Data is encapsulated: only that file can access it. This is as close as C can get to encapsulation where multiple functions can access a static variable.

Global variables are bad no matter what. Static file variables have the benefits of a private static variable but none of the drawbacks of a global variable.

The only issue is unlike with a true private static variable as in C++, other files can declare an extern variable matching the declaration and you cannot prevent access. In other words, you are relying on the honor system to avoid turning it into a global variable.

Related Solutions

C++ Object Management – Early Destruction of Objects in C++

However, though versions of this text appear all over on the internet my question is not completely answered by this explanation. Though it may be implied, since global variables always seem to be static it would be nice to have a straight out answer.

If you didn't explicitly create it, you don't need to explicitly destroy it. Let's just remove some of the words from your standard quote:

Static: Objects declared in global or namespace scope (§6.3.4) ... are created and initialized once (only) and ‘‘live’’ until the program terminates (§15.4.3). Such objects are called static objects.

So, if you declare an object with global or namespace scope, it is static, and its lifetime is roughly the program lifetime.

By analogy, consider normally-scoped local variables:

void foo() {
    std::string s;
    // code
}

now there is no way to destroy s without exiting its enclosing scope. If you explicitly destroy it in-place, the destructor will still be called again when the scope exits.

Now, consider global and namespace scope to be the top-level scope of your program. You enter this scope before main (which is nested inside the global scope) and exit it after leaving main. This top-level scope lives exactly as long as the program, and you're no more able to destroy the its objects early than you are objects in any other scope.

There is some subtlety about exactly when the constructor gets called (generally before main starts, with a fudge to allow dynamically-loaded libraries without having to talk about platform specifics), when the destructor gets called (relative to exit handlers, say), and the relative ordering of these for different statics (not well-defined, so don't make global initialization or destruction depend on other globals).

Of course, if you want the object to be global for convenience, you can still choose to have explicit setup/cleanup calls instead of using the ctor/dtor for this.

Design – Are static global variables as bad as global variables? How to avoid using them

Whenever the key is changed(by some other threads), my call back notifier is executed in which I update my static global variable with the new key. This key is used everywhere in the program to decrypt some data.

What is trapping you in this kind of thinking is the concept of "the key". It should be "a key".

You think of the key as global so anything that would hold it must be global. Imagine your requirements change and suddenly there are 5 keys running around.

Can't imagine that? Fine, imagine 5 systems, that do nearly the same thing, that must have different keys and all need to be part of your application. How much of your code could be reused?

The key belongs in a context. Within that context there will be only one key. But that doesn't mean there will only ever be one context.

Rather than force everything to find this key by knowing "the one true key" tell them what context they are in by passing them some way to find the key they care about.

That means the key will still only be stored in one place. But now only one place decides where that place is. If you make it global then everything has to know where it is and AGREE on where that is. Ick.

Best Answer

Related Solutions

C++ Object Management – Early Destruction of Objects in C++

Design – Are static global variables as bad as global variables? How to avoid using them

Related Topic