News for hackers. Stuff that matters.
Re:Global variables are bad (2013) by kyberias on Thursday July 26, 2018 @03:05AM (#17615586)
The threads could take a pointer/reference to the "stop variable" and use the reference instead of accessing the global variable directly. That allows you to mitigate many problems of global variables. Sorry, if you already do this.
Re:Global variables are bad (2013) by dev_dull on Thursday July 26, 2018 @03:13AM (#17615635)
Honest question but what do I really gain in this scenario? Now all worker function arguments are N+1. I feel like it’s the waterbed affect and the complexity is simply pushed around elsewhere.

It seems like there’s simply a reasonable cognative “maximum” of global before it becomes unworkable. My gut tells me it’s between 1 and 4.

Re:Global variables are bad (2013) by Someone on Thursday July 26, 2018 @03:32AM (#17615722)
Gain? You could pass different pointers to each worker function, giving you a way to partially shutdown your process, or to shutdown some workers first, and workers they depend on later.

Of course, if you don’t need that, it’s not a gain, and a global is fine.

Globals also are fine if you are resource constrained (e.g. if you have a few kilobytes of RAM or even less) Getting your code running in it may trump everything else.

Re:Global variables are bad (2013) by setr on Thursday July 26, 2018 @03:23AM (#17615679)
I think the main benefit is that every function relying on the stop variable is clearly defined as such, as opposed to having to find out manually who is reliant on it based on usage; its not so much moving complexit around as it is making things more explicit. im not sure how useful this is in practice though, for the common case
Re:Global variables are bad (2013) by kyberias on Friday July 27, 2018 @04:06AM (#17624321)
For one thing, you immediately make that function unit-testable.