Printable View
Is it possible to declare TOO many variables in a C++ program, or are the number of variables only equal to the amount of functions set? I have quietly wondered about this for awhile and I would say the answer is "No, one cannot have too many variables.". How could you? If it is a good idea to not let your variables run rampant, please explain why. Much appreciated,
reRanger
complete n00b speaking, but id assume its just a matter of memory being allocated and if your program has an audience or not. But from strictly a "too many" standpoint, hell if i know :o
Like zeus said its a matter of memory you don't want to declare too many variables. I'm not sure what you mean by letting your variables run rampant but I don't see why you would want anymore variables than you need. Having extra doesn't make your program run any better :)
Variables need to be kept track of somehow. Static memory is frequently limited and can be overflowed readily by multiple levels of recursion or declaring containers of large size. Dynamic memory is limited by the amount of RAM or memory that can be used like RAM. But even dynamic memory is finite. So, in theory, you could run out of room. In practice, it would seem unlikely, however, if your program has any realistic design.
If you think you have too many variables, then your program design is wrong at some point. Either you have too large functions or something else.
The question is, however, what too many is.
I would say that in modern systems memory is no longer a concern. There's a ton of it available.
Just manage it correctly and don't use null pointers to write to memory and you should always have plenty of room. Perhaps in the old days memory was a precious resource but it's just not anymore. Most systems have at least a gig of memory or more. Your variables are not going to ever fill all that up.
But if we are talking about having a lot of global variables sitting around in space then yes your approach is incorrect. C++ has many many data structures geared specifically towards being able to control the lifetime(scope) and ownership of variables, data, functions, and other classes or objects.
I'm not saying that you must derive till your head explodes because that is not the answer either. But your classes should contain variables that are important only to that class. They should be private, by default, but this is not always the best design.
Global variables are not all bad but they are not always all good either. Use them wisely.
i dunno, personally i think most run about half a gig, though i would love a gig lol. Pointless critacism though lol, sorry :o.Quote:
Most systems have at least a gig of memory or more.
You should only need as many variables as your program design calls for. Your program is just tyring to represent (abstract) whatever simulation or model or equation etc. It is a matter of design. if you need an array of 256 integers that you use throughout the program then create a static array so you don't waste time allocating and recreating it each time you need it. if you only need a temporaray space to store a result then create the variable within the scope of the function so it only exists for a short time and then the memory is freed. If you have a program that creates 10,000 troops each one has to be kept track of in some variable or struct or class Your going to have to keep them in memory but your program will run slower (probably much much slower or not at all) unless you run out of memory first. With a little thinking you can probably come up with a better representation or an aproximation so you don't have that many variables to deal with but still can get the same or similar results. Most people make 1 troup represent 40 or 100 or some larger number and then they act as a unit instead of individual troops. What are you designing that needs so many variables?
Memory is always a concern. I would say that you should develop with 128 MB minimum in mind, which is still a lot, but you should also develop with twenty processes that have to share these 128 MB in mind.
Your program should use exactly as much memory as it needs. More, and it's a hog, less, and you probably have to make big tradeoffs with execution speed. Design is the key.
I'm running 256 o_O, not all of us have high end computers btw, quite the contrary.
There is a finite limit to everything besides nothingness btw ;), you might have some fun messing around with dynamic allocation later, good way to freeze your comp. Memory management is fun ^_^
Well as a hobbyist game designer I really don't worry much about memory. When I'm in Direct3D the system is mine and I make sure of it. I need the whole system and all the resources that Windows can possibly give to me. I don't need to cooperate with other programs in the system and I only have to process those messages that are relevant to my game. I need all the memory I can get and I need fast access to the AGP bus and AGP card. I need to be able to run independent code on the video card GPU, I need super-low latency sound effects mixing, etc., etc. All of this requires that I have as much control of the system as Windows is willing to relenquish. As long as I don't frag COM, the heap or Windows in any way then my code has done what it is supposed to do.
This approach, however, will not work if you are programming a Windows-based application. They are two different paradigms.
Including that which you are stealing from yourself by using careless memory management. Besides, the smaller your working variable set, the fewer cache misses you have, the faster your game runs.Quote:
I need all the memory I can get
I dont have careless memory management but I'm also not worried about how many variables I have because 90% of them are in classes. Careless would be not releasing COM objects, not deleting objects, and not tracking resources or allocating them willy nilly which I don't do. All resources are tracked by container classes and it is the job of the container class to destroy/release/create objects. In fact in my system you cannot directly create any objects that require Direct3D resources. You must go through the container class and you must have a valid ID in order to access your object(s), if the class even provides a way to directly access the object. In some cases there is no need. You create the object and its properties and the engine updates it and destroys it at the appropriate time. All resources - Materials, Lights, Textures, Texture Animations, Models/Meshes, Sounds, Music, Scripts, etc., have container/management classes.
But I still need a lot of memory and a lot of resources for the game engine. That was my point. Not trying to hijack the thread here....the answer to the question is no. As long as there is memory available either for the stack, code (I don't recommend sticking variables in the CS), or the data you can use it for storage.