Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Global variables are not the problem

codestyleandtaste.com

Post reply on HN
Print view View original

141–150 of 165 posts

Re: Global variables are not the problem

#141

Post by billforsternz »

billforsternz wrote: post #41

From the article> "Static Function Variable: In C inside a function, you can declare a static variable. You could consider this as a local variable but I don't since it's on the heap, and can be returned and modified outside of the functions. I absolutely avoid this except as a counter whose address I never return." These variables are not on the heap. They are statically allocated. Their visibility is the only thing…

Sorry, I owe the author an apology for saying that they "cast shade" on the idea of returning the value of the static variable. Actually they, quite correctly, cast shade on the idea of returning the address of the static variable. I'd edit the original message, but I am (far) too late. I just noticed my mistake. All I can do is add this apology, for the record.

Re: Global variables are not the problem

#142

Post by darioush »

cogman10 wrote: post #140
darioush wrote: post #125

Global variables are a programming construct, which like other programming constructs is neither bad nor good. Except, due to the takeover of workplaces by the best practices cult, instead of reasoning about tradeoffs on a case by case basis (which is the core of coding and software engineering), we ascribe a sort of morality to programming concepts. For example, global variables have drawbacks, but so does re-writin…

Depends a bit on the language. A global variable in a language with parallel operation is often a terrible idea. The problem with globals and parallel operations is they are an inherent risk for race conditions that can have wild consequences. In some languages, for example, a parallel write to a field is not guaranteed to be consistent. Let's assume in the above example `counter` was actually represented with 2 byte…

Yes, mixing some concepts in programming is a terrible idea.

Perhaps this is also widely unpopular, but it's the parallelism that needs to be treated with care and the additional caution, as often the parallelism itself is the terrible idea.

Concurrent code often has unpredictable performance due to cache behavior and NUMA, unpredictable lock contention, and the fact that often there is no measure of whether the bottleneck is CPU or I/O.

What most people want from concurrency (like computing the response to independent HTTP requests) can be done by separate processes, and the OS can abstract the issues away. As another reference, the entire go language is designed around avoiding shared memory (and using message passing -- even though it doesn't use processes for separation it encourages coding like you did).

But also sharing memory between processes can be handled with care via mappings and using the OS.

Re: Global variables are not the problem

#143

Post by levodelellis »

billforsternz wrote: post #141
billforsternz wrote: post #41

From the article> "Static Function Variable: In C inside a function, you can declare a static variable. You could consider this as a local variable but I don't since it's on the heap, and can be returned and modified outside of the functions. I absolutely avoid this except as a counter whose address I never return." These variables are not on the heap. They are statically allocated. Their visibility is the only thing…

Sorry, I owe the author an apology for saying that they "cast shade" on the idea of returning the value of the static variable. Actually they, quite correctly, cast shade on the idea of returning the address of the static variable. I'd edit the original message, but I am (far) too late. I just noticed my mistake. All I can do is add this apology, for the record.

I didn't mind. I knew I'd hear a lot of disagreements and incorrect thoughts. My next article has a lot of examples which should make things easier to digest.

One thing I dislike about compsci is everyone has different definitions for everything. If people say static variables are not on the heap fine, but you can easily see the address of a static variable and global variable being in the same 4K page

Re: Global variables are not the problem

#144

Post by levodelellis »

tcoff91 wrote: post #86
billforsternz wrote: post #41

From the article> "Static Function Variable: In C inside a function, you can declare a static variable. You could consider this as a local variable but I don't since it's on the heap, and can be returned and modified outside of the functions. I absolutely avoid this except as a counter whose address I never return." These variables are not on the heap. They are statically allocated. Their visibility is the only thing…

Just in case anyone still doesn't understand what that means to be statically allocated. It means that they are allocated in the Data Segment, which is a separate area of virtual memory from the stack and the heap.

Only if it's const. Otherwise the data is copied into memory you can write to

Re: Global variables are not the problem

#145

Post by levodelellis »

Tainnor wrote: post #90
caspper69 wrote: post #16

Earlier quoted context omitted.

Hard disagree. If I have 500 functions, I don't want to extrapolate out the overhead of passing a state object around to all of them. That's a waste of effort, and frankly makes me think you want to code using an FP paradigm even in imperative languages. Module-level and thread-level "globals" are fine. You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing…

I got into this argument with my former coworkers. Huge legacy codebase. Important information (such as the current tenant of our multi-tenant app) was hidden away in thread-local vars. This made code really hard to understand for newcomers because you just had to know that you'd have to set certain variables before calling certain other functions. Writing tests was also much more difficult and verbose. None of these…

Ouch, I partially address this in the next article

Re: Global variables are not the problem

#146

Post by levodelellis »

cies wrote: post #103

> Global Variables Are Not the Problem It should have been "Mutability is the Problem, Globalness is not".

I'm the author. No, I completely disagree. No one ever complains about logs and malloc except having too much of them - A line I removed from this article

The next article has examples and IMO much better, but makes no mention of action at a distance, and currently makes no mention of how people use clone to prevent mutability.

Re: Global variables are not the problem

#147

Post by roenxi »

bandrami wrote: post #134
roenxi wrote: post #116

Earlier quoted context omitted.

Because there is no intent, need or reason to vary it. Nearly everything in RAM is technically a global variable to someone who is keen enough. Programming depends on a sort-of honour system not to treat things like variables if it is hinted that they shouldn't and it doesn't make sense to. Otherwise we can all start making calls to scanmem & friends.

Right but closing over a state with a function and giving that closure a name seems to quack like a duck to me. Maybe it's just because I'm a scheme guy and we're more upfront about this.

The situation is ugly because there is global state by design. But I don't see why the fact that the closure is stored in a mutable location would be a concern for you. Can you think of any conditions where someone would modify it? I'm not really seeing it, and I don't know what your alternative suggestion is going to be to stop them technically.

I can tell you when someone would modify a counter variable - every time it needs to be incremented. It leaves open a lot of room for bugs in unexpected parts of the code. Gating access behind a stateful function makes doing the wrong thing more expensive.

Re: Global variables are not the problem

#148

Post by Panzer04 »

ijustlovemath wrote: post #127
Panzer04 wrote: post #72

Earlier quoted context omitted.

Could you expand on this? I don't understand the point you're making, or how it's useful.

static consts in C carry their identity through their (fixed, unchanging) pointer address. Lets say you have a business rules engine, that's only meant to ingest threshold values from a certain module. You want to know if the 3.0 you're using is coming from the correct place in the code, or if there's a programming error. With a define, there's not enough additional information to be able to. With a static const, you…

So it's easier to guarantee the identity is correct? That doesn't stop you from using the incorrect identity, though.

I'm not quite sure I understand how this is better than a define - if you know enough to know whether you're using the correct value, it can just as easily be a define?

I think I can see the idea, but I'm probably not paranoid enough to understand how it's helpful XD

Re: Global variables are not the problem

#149

Post by tcoff91 »

levodelellis wrote: post #144
tcoff91 wrote: post #86

Earlier quoted context omitted.

Just in case anyone still doesn't understand what that means to be statically allocated. It means that they are allocated in the Data Segment, which is a separate area of virtual memory from the stack and the heap.

Only if it's const. Otherwise the data is copied into memory you can write to

Isn’t there a part of the data segment that is writable? Initialized vs uninitialized data segment right?

Re: Global variables are not the problem

#150

Post by bb88 »

grandempire wrote: post #8
bb88 wrote: post #2

Please no. Singletons if you must. At least you can wrap a mutex around access if you're trying to make it thread safe.

Why are singletons better? That's just a global object. > wrap a mutex What if my program has one thread? Or the threads have clearly defined responsibilities?

In complex systems trying to hunt down intractable bugs on global variables is a terrible developer experience. I've done it before.
Post reply on HN