Global objects?
Hi, I have a question regarding objects. I have 4 classes that, in my main file, I need to create objects from. In the main.cpp file I have multiple functions that use these objects. Is it ok to create these objects as globals, or is it best to create them in the main method, and then pass them around as parameters. I was originally passing them as parameters. But it then got to the point I was only passing functions the objects because eventually that function called another function, and it seemed a bit stupid. But I heard globals should not really be used. Can someone please clarify this?
If you're passing the same objects to all your functions, that hints at one of two things. Either a) you have subdivided your code into functions excessively, or b) you actually need a fifth class that contains an instance of each of those other four classes.
Imagine you have a mansion and you need to give keys to your butler, your cook, and your plumber. The correct way to do it is to give your butler a key for the front door, your cook a key to the kitchen, and your plumber a key to the basement. The lazy way to do it is to put the same lock on all the doors and to give everyone the same key. If someone steals from you you'll have no idea who it was because everyone has access to every part of your house.
Likewise, you want to give your functions access to the least possible amount of data. If you find that your data becomes corrupt and there's only one or two functions that are able to access that object, you only need to debug those functions. If every function is able to access that object, you have no choice but to debug the entire program.
Imagine you have a mansion and you need to give keys to your butler, your cook, and your plumber. The correct way to do it is to give your butler a key for the front door, your cook a key to the kitchen, and your plumber a key to the basement. The lazy way to do it is to put the same lock on all the doors and to give everyone the same key. If someone steals from you you'll have no idea who it was because everyone has access to every part of your house.
Likewise, you want to give your functions access to the least possible amount of data. If you find that your data becomes corrupt and there's only one or two functions that are able to access that object, you only need to debug those functions. If every function is able to access that object, you have no choice but to debug the entire program.
globals seem pretty cool and easy to use at first, because they are. The problems they cause get worse the larger your project is, the more people that use it, and the more you use complex features.
consider...
say you have global variable x.
someone else has a local variable x in a function. Now it becomes less than clear which x is which inside the other function. You can figure it out, but after reading 10 routines where x is the global, then seeing it in the 11th where it is a local, its easy at that point for fatigue to cause you to miss the detail, misunderstand what the code does, and make an inappropriate change or chase down a nonexistent bug or some other mess.
now say you use this 'x' as a result variable for whatever. You have a menu, user picks option 1, function 1 is executed, result dumps to x, user picks 2 and funcion 2 executes and dumps to x, etc. Works great. Then your new intern takes this code base on a similar but slightly different project, where instead of a user, the choice is picked by the computer somehow and his code will be processing a LOT more data than the one at a time human usable version. So he threads it all up, to make it run efficiently. Thread 1 calls function 1, thread 2 calls function 2, and they finish about the same time, twice the work in the same amount of time! Except ... where are your 2 results? ... When the program looks at the results, one of them will be wrong, whichever finished last will be see as the result for both.
Those are just 2 of the problems with globals that touch the tip of the kinds of problems they cause once you stop writing 2 page or less programs all by yourself for school. Or, to say it another way: as soon as you get a job, your bad habits on this and other issues will quickly need to be corrected or you may lose that new job.
There are a handful of rare places where a global is considered OK, but for now try to write as if you could not make them at all. There are also multiple tools to make them safer, such as wrapping them up as static class members or putting a namespace around them. Consider the special cases to be an exception to the rule, though, and the rule is, do not use them.
consider...
say you have global variable x.
someone else has a local variable x in a function. Now it becomes less than clear which x is which inside the other function. You can figure it out, but after reading 10 routines where x is the global, then seeing it in the 11th where it is a local, its easy at that point for fatigue to cause you to miss the detail, misunderstand what the code does, and make an inappropriate change or chase down a nonexistent bug or some other mess.
now say you use this 'x' as a result variable for whatever. You have a menu, user picks option 1, function 1 is executed, result dumps to x, user picks 2 and funcion 2 executes and dumps to x, etc. Works great. Then your new intern takes this code base on a similar but slightly different project, where instead of a user, the choice is picked by the computer somehow and his code will be processing a LOT more data than the one at a time human usable version. So he threads it all up, to make it run efficiently. Thread 1 calls function 1, thread 2 calls function 2, and they finish about the same time, twice the work in the same amount of time! Except ... where are your 2 results? ... When the program looks at the results, one of them will be wrong, whichever finished last will be see as the result for both.
Those are just 2 of the problems with globals that touch the tip of the kinds of problems they cause once you stop writing 2 page or less programs all by yourself for school. Or, to say it another way: as soon as you get a job, your bad habits on this and other issues will quickly need to be corrected or you may lose that new job.
There are a handful of rare places where a global is considered OK, but for now try to write as if you could not make them at all. There are also multiple tools to make them safer, such as wrapping them up as static class members or putting a namespace around them. Consider the special cases to be an exception to the rule, though, and the rule is, do not use them.
Last edited on
Ok I understand now why creating them as globals would be a bad idea. I am unsure the best way to approach my issue, but thank you for explaining why globals are not the best way, and thank you for the analogies, they are very helpful.
Topic archived. No new replies allowed.