Thread: dark side of global variables

Originally Posted by Matus

While TLS is not standard, it is certainly an option that defies the problems posed by multi-threading without simply hoping volatile will save the day. I never said I was pro-globals. I am simply offering solutions posed by the original poster's scenario.

Yes, but it's no longer a global variable - it's a variable accessed through a pointer (in some way - it may be an offset from a segment variable in x86, but that's for all intents and purposes a pointer anyways) - and you can always do that yourself with a little bit of extra pointer stuff.

And volatile has nothing at all to do with TLS - it removes the need to use volatile because the memory is no longer accessible from multiple threads, but it's otherwise unrelated to volatile. Volatile simply means "compiler, please be aware that the use of this variable may change even if you don't think it will from looking at the code", which essentially means "do not optimize away reads/writes of the variable", and it was originally introduced in C as a means to allow the compiler to optimize your normal variables, but tell the compiler that hardware registers that aren't memory needs to be treated differently. It may come in handy with threads too, but it's a side-effect.

--
Mats

Originally Posted by MK27

Isn't searching through the code necessary from time to time?

Unfortunately, but we should do everything we can to make it easy for future developers.

Plus all the globals are at the top with the function prototypes! True, without searching for the variable, you wouldn't be able to connect it with a particular function. But everything is fine with the compiler anyway.

This kind of approach makes your design non modular. It prevent you from reusing your code in another project, or a different part of the same project. You have to link the entire project to use a single function. Or that function, despite preforming a generic operation, cannot be used, because it hard codes the data.

On the other hand, a pointer doesn't have to have the same name all the time, so it's bound to change.

This is a positive because it allows generic reusable function. So instead of having a function called addPoints(), that sums up a particular array of scores, you can write a generic function called addList() that sums all the elements in any list. This makes for reusable, modular code.

In short, this kind of use of global just doesn't scale well.

Originally Posted by matsp

--
Mats

Kk Mats no problemo, good reading, good posts!

Just a point on "reading through the code": I did "dir /s *.h *.cpp" on ONE of the directories of the code I'm working on, that I have worked a bit with: 2.9MB. Another one, that I know very little of: 11.3MB.

Entire tree of our groups work: 35 MB (in about 3000 files).

That's an awful lot of code to "read through" - in fact, I couldn't do my job if I read through all the code before I worked on it - even in a small project with, say, a few hundred kilobytes of code, to understand the use of all variables in all places becomes an impossible task.

--
Mats