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

41–50 of 165 posts

Re: Global variables are not the problem

#41

Post by billforsternz »

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 that differentiates them from global variables and static variables defined outside of functions.

I think such variables can be useful, if you need a simple way of keeping some persistent state within a function. Of course it's more state you are carrying around, so it's hard to defend in a code review as best practice.

Amusingly, you can modify such variables from outside the function, simply by getting your function to provide the modifying code with a pointer to the variable, eg by returning the variable's address. If you do that though you're probably creating a monster. In contrast I think returning the value of the static variable (which the author casts shade on in the quote above) seems absolutely fine.

Edit: I should have stated that the number one problem with this technique is that it's absolutely not thread safe for obvious reasons.

Re: Global variables are not the problem

#42

Post by grandempire »

catlifeonmars wrote: post #28
grandempire wrote: post #15

Earlier quoted context omitted.

Because as a programmer I have responsibility for the technical soundness of the program, and I don't create threads haphazardly. > when i thought i understood multi-threaded code, but didn't. All the more reason to carefully plan and limit shared state among threads. It's hard enough to get right when you know where the problems are and impossible if you spray and pray with mutexes.

Yeah but just because you do the right thing doesn’t mean that others will. That one person that creates threads haphazardly will wreak havoc and at scale this will happen. It’s an unstable equilibrium to put the onus of program soundness on the contributors to a program.

> That one person that creates threads haphazardly will wreak havoc

What if someone comes along and starts adding threads and doesn't check what they are accessing? And doesn't read the documented invariants of the design?

Well I don't think any project can succeed if that's the level disorganization.

Are there certain kinds of bugs that are easy to regress last minute? Yes. A brand new thread without limited state is not one of them.

> put the onus of program soundness on the contributors to a program.

Who then is responsible for making sure the program is correct?

Re: Global variables are not the problem

#43

Post by caspper69 »

pdimitar wrote: post #40
caspper69 wrote: post #38

Earlier quoted context omitted.

My comment was not intended to be personally degrading to OP. Apologies if it was taken that way.

I did not say you are targeting OP. I meant that you are degrading your parent commenter. This: "You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing around a global state object to every single method invocation." ...is neither productive nor actually true. But I'll save the latter part for your other reply.

I'll take my medicine. :)

I'm not above being put in my place and being shown the light.

(And when I said OP, I did mean the parent poster)

You should also understand that the "you" in my comment you quoted is the colloquial you and not necessarily the parent poster.

So lay it on me.

Re: Global variables are not the problem

#44

Post by pdimitar »

caspper69 wrote: post #43
pdimitar wrote: post #40

Earlier quoted context omitted.

I did not say you are targeting OP. I meant that you are degrading your parent commenter. This: "You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing around a global state object to every single method invocation." ...is neither productive nor actually true. But I'll save the latter part for your other reply.

I'll take my medicine. :) I'm not above being put in my place and being shown the light. (And when I said OP, I did mean the parent poster) You should also understand that the "you" in my comment you quoted is the colloquial you and not necessarily the parent poster. So lay it on me.

OK, I will.

But I also got a notification about a big comment you posted but it is now deleted. Did you want to rewrite it or did you give up on it?

Re: Global variables are not the problem

#45

Post by liontwist »

catlifeonmars wrote: post #29
grandempire wrote: post #13

Earlier quoted context omitted.

The burden is on the programmer adding a new thread to know what they can safely access. The conclusion of your argument looks like 2000s Java - throw a mutex on every property because you never know when it will need to be accessed on a thread. Designs that spread complexity rather than encapsulate it are rarely a good idea.

That’s sounds more like a weakness of the language: that preventing data races is not automatically tracked for you, no?

If you care about performance, many locks across many pieces of shared state is always a bad idea.

If you don’t care about performance and want safety you should be using processes. Explicit shared memory is safer than implicit.

and yes. Better thread management tools are always welcome when we can get them.

Re: Global variables are not the problem

#47

Post by Gibbon1 »

rafaelmn wrote: post #21
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…

You get functions that are easily testable in isolation with all state provided in parameters. You also get explicit dependencies and scoping controlled by caller. I don't mind globals but saying you get nothing for avoiding them is :/

I tend to use getter and setter functions to access globals and manage state.

Advantage only the function that depends on the global needs to bring in the dependency.

Re: Global variables are not the problem

#48

Post by caspper69 »

pdimitar wrote: post #44
caspper69 wrote: post #43

Earlier quoted context omitted.

I'll take my medicine. :) I'm not above being put in my place and being shown the light. (And when I said OP, I did mean the parent poster) You should also understand that the "you" in my comment you quoted is the colloquial you and not necessarily the parent poster. So lay it on me.

OK, I will. But I also got a notification about a big comment you posted but it is now deleted. Did you want to rewrite it or did you give up on it?

I could not initially reply to you. Your comment rubbed me the wrong way, because I had no intention of trying to degrade anyone, and frankly, I was offended. But I thought better of my hasty and emotional response. I would rather take a deep breath, re-focus, re-engage, and be educated in a thoughtful dialog than get into a mud slinging contest. I am always willing to be enlightened.

Re: Global variables are not the problem

#49

Post by catlifeonmars »

grandempire wrote: post #42
catlifeonmars wrote: post #28

Earlier quoted context omitted.

Yeah but just because you do the right thing doesn’t mean that others will. That one person that creates threads haphazardly will wreak havoc and at scale this will happen. It’s an unstable equilibrium to put the onus of program soundness on the contributors to a program.

> That one person that creates threads haphazardly will wreak havoc What if someone comes along and starts adding threads and doesn't check what they are accessing? And doesn't read the documented invariants of the design? Well I don't think any project can succeed if that's the level disorganization. Are there certain kinds of bugs that are easy to regress last minute? Yes. A brand new thread without limited state i…

> Who then is responsible for making sure the program is correct?

I’d say this is mostly a function of the language or framework.

After that, it’s up to the tech leads to provide access patterns/examples that align with the needs of a particular project.

My point is not so much that you shouldn’t ever think about the implications of your code, just that contributors are humans and any project with enough contributors will have a mix of contributors with different knowledge, experience and skill sets. If you are leading one of those, it would behoove you to make doing the right thing easy for later contributors.

Re: Global variables are not the problem

#50

Post by Jtsummers »

caspper69 wrote: post #48
pdimitar wrote: post #44

Earlier quoted context omitted.

OK, I will. But I also got a notification about a big comment you posted but it is now deleted. Did you want to rewrite it or did you give up on it?

I could not initially reply to you. Your comment rubbed me the wrong way, because I had no intention of trying to degrade anyone, and frankly, I was offended. But I thought better of my hasty and emotional response. I would rather take a deep breath, re-focus, re-engage, and be educated in a thoughtful dialog than get into a mud slinging contest. I am always willing to be enlightened.

A tip, in your profile you can set a delay which is a number of minutes before your comments will become visible to other people. Mine is set to 2 right now. This gives you time to edit your comment (helpful for some longer ones) but also to write some garbage response and then think better and delete it before anyone's the wiser.

It's also helpful to give you time to re-read a mostly good, but maybe not polite, response and tone down your response.

Post reply on HN