I Like and Use Global Variables
codestyleandtaste.com
codestyleandtaste.com
Your program must be really small and scoped for this to make sense.
Also, kudos for providing so many corner cases to avoid that are non-trivial to formulate.
It feels like one of those "it's not impossible to do right" cases.
I'll just cite one evaluation point from the post:
> It's extremely easy to use incorrectly.
> Your program must be really small and scoped for this to make sense.
to me suggests that it's not really global state if your program has to stay small and scoped. In a sense, your program has just become the context boundary for the state, instead of a function, or class, or database.
I realise that this line of argument effectively leads to the idea that no state is global, but perhaps that gives us a better way to understand the claim that 'global variables can work', which they undoubtedly can. It's fine for a program (or a thread, as in the original article) to be the context which bounds a variable's scope.
It's still possible to wrap all that as nested state in a single global, and it works just fine:
https://github.com/floooh/chips-test/blob/613dbfe907104f4110...
That's a single mutable global with all application state, but inside that global are nested structs and the code working on those structs takes essentially a 'this' pointer. This approach works well since it enforces a strictly hierarchical code and data structure with a single root-struct (and also a single root-source-file) at the top.
I find the append_work especially egregious. Never ever use a bloody global for that! Goodness gracious me. What an absolute and utter waste that provides zero utility. If you have a job system just pass a damn handle to the job queue. Good lord.
If everyone spent a little effort to not use globals the world would be a much better place. The value add of globals when they are mildly useful is so inconsequential such that it's basically never worth the effort.
I think it’s somewhat similar to unchecked memory access. Used correctly it works just fine and offers extremely high performance. Unfortunately, history has shown that over enough time mistakes will be made. As an industry we’re now to the point of actively denouncing entire languages over the risks of unchecked memory access.
Using software development patterns that rely on the engineers to follow a bunch of rules to do things correctly will eventually burn you. Better to avoid them entirely if at all possible.
However this just underlines again why globals are usually good to avoid. It takes rigor not to make mistakes that can completely mess up with program state.
I also strongly disagree with the benefits author advances for having global. Code feels actually less spaghetti when things are properly scoped and not accessible from everywhere, which hides extremely well dependencies and makes it way harder to reason about the code.
One famous exception to that is indeed logging (which in itself is based on global state when printing to stdout or stderr anyway).
And also
> on account of how few places your object can be stored to
you can store things in a single place, just once, without the need for globals.
Most languages make global and static variables thread-global by default, and making them thread-local is more work. I can see why, but that piece of language design causes a lot of global variable problems.
Also: you can simplify a lot of problems by deciding that something is going to be limited to n=1, whether that's variables or threads, and then a business reason comes along where you really want to have n=2. Suddenly every global is a source of regret.
No, not in the face of any sort of concurrency it doesn't...
That is completely untrue.
Best case scenario is that the loads and stores are interleaved, which leads to multiple threads returning the same value when calling counter(), which will guarantee crashes elsewhere in the program (the purpose of functions like these is to produce UNIQUE values, after all). But it's undefined behaviour in any case, it's just unacceptable to put in a C/C++ code base.
Constant global variables can be very useful. Mutable global variables can be totally fine in a singlethreaded (e.g. typical embedded) program. I agree that you should still use them with caution, but every advice that says: "don't do $X" should come with instructions under which circumstances it is valid and under which it isn't — and how to get the intended behavior instead with e.g. message queues, locks or whatnot.
I fail to see how does that relate to the article in question.
The author provided an example for which counter() works well, he didn't claim that the same "pattern" would be good for 100% of the use cases.
static int prv_counter;
int counter() { return ++prv_counter; }
If you want to do this (and you shouldn't, because global state is bad for 14 other reasons), at the very least, make it thread safe and not trivially overflowing:
static std::atomic<int64_t> prv_counter { 0 };
int64_t counter() { return 1 + prv_counter.fetch_add(1, std::memory_order_relaxed); }
Like, this is not awesome, and you shouldn't do it, but it's at least not a total disaster.
EDIT: actually, this is also bad, because the `prv_counter` is not really private at all. The better way to do that would be:
int64_t counter() {
static std::atomic<int64_t> prv_counter { 0 };
return 1 + prv_counter.fetch_add(1, std::memory_order_relaxed);
}
The point is that there is no solution that works for all use cases. If you always attempt to write fully generalized code like that you'll end up with tons of unnecessary complexity. Solve the problem at hand, not some hypothetical.
The author even specifies a rule that covers your case:
"If you're using threads, global and static variables should be thread local. If they are not then the discussion becomes about sharing data across threads and synchronization, which is a different topic."
Doing this is planting a time-bomb in your code-base. It's going to lay dormant for a long time, and then explode, and be impossible to debug. This is why mutating global variables is `unsafe` in Rust, which is the right call. There is literally no C or C++ code base where I would allow this to pass code review, regardless of how single-threaded the author thinks it is.
> needlessly complex
It looks more complex than it is because I set the memory order to relaxed as an optimization. You could also write this:
int64_t counter() {
static std::atomic<int64_t> prv_counter { 0 };
return ++prv_counter;
}
If this was a junior making this mistake, I would sit down and talk to them and patiently and explain the issues. If you're writing a blog post on the internet saying "this is a good way to write code, do it like this!", I'm sorry, but I'm going to be very harsh. We haven't even discussed using `int` and not properly scoping the static, also rookie mistakes. Someone is going to read this article, and think this kind of code is ok. It is not.
> "If you're using threads, global and static variables should be thread local. If they are not then the discussion becomes about sharing data across threads and synchronization, which is a different topic."
This is nonsense. First off all, a counter like this wouldn't work if it was a thread_local, because then you'd get duplicate values. If duplicate values are ok, why is it global state at all? The only reason you'd make it global state is to produce unique values for that process run. And the general sentiment is like saying "this is how you drive drunk safely. We're not discussing keeping control of your car and crashing into a tree, that's a different topic".
This IS why global variables are bad! Not the only reason, but a pretty darn big one!
In your context what you say is definitely the correct take, but I stand by my take that there are relatively simple programs written by individuals/small teams that don't need to be complicated by corporate scale concerns.
In a well designed code base, only a very small part of the code should need to worry about concurrency and parallelism.
Immutable global state is fine to be accessible from the whole code base.
Pure functions are best of course, but you can't build real-world things entirely from pure functions.
The problematic approach lives somewhere inbetween, passing context/object references into deep callstacks isn't really a good solution for anything.
That's just plain wrong. There's even a language built entirely around pure functions: Haskell.
Not going to use it in anything I get paid for though, lol. At one point there was a commonly accepted "singleton" pattern for things like logging but that's just globals with extra steps. In Go I just create services in my main and pass them around where needed.
We stick to these kinds of rules because most people are not great programmers all the time. It's just mostly better to do the safe and boring thing most of the time.
I’m sorry but no. Humans are human and mistakes will be made. I’ve lost count of the number of esoteric bugs I’ve had to track down due to global state being changed and not put back properly.
If you have to qualify a pattern with rules that are easily forgotten or open to corner case bugs, it’s far better to just not use that pattern in the first place.
1. It should be hard or impossible to use incorrectly. For example, counter() keeps increments consistent. 2. If you change observable state, restore it.
That can be summarised as "To prevent mistakes: Don't make any mistakes". It made lots of sense once I saw this was by a C++ programmer, C++ is the language with, as a prominent C++ practitioner put it: False Positives for the question: Is this a valid program?
If you're used to a language which gaslights you by having the compiler not emit any diagnostics whatsoever and just calmly handing you a nonsensical output executable because what you wrote was subtly wrong obviously global variables seem fine, what's not to like? You just have to be inhumanly competent at all times, which was the baseline requirement for the entire language.
Sure, for example it turns out that by "global" you mean "thread local" and I expect lots of people don't agree with you about that.
If your narrow the usage of a global within a file you can get a lot of mileage. That's not how people tend to use globals and why I wanted to write about it
In any case, I think variables that are “global” but encapsulated in this way lose the potential for harm we associate with a global variable the whole program may be directly reading and writing.
No, please don't
let's = let us, it is for suggestions
lets = I let, he-she-it lets, it's the verb form
This is what you should do if you must use globals, but it doesn't really give any advantages.