Skip to main content
gamedev.net
🔒 Locked

Saving space in C++ using pointers

Started by jollyjeffers Dec 29, 2003 at 6:54 AM 4 replies 500+ views
Original Post
jollyjeffers
jollyjeffers
hi, I''ve got an interesting dilema in the design of a new C++ system.. its not my enforced "rule", but there are going to be a huge number of global variables in a namespace available to the rest of the application. Now, almost all of these globals will be primitive types - int, float, char etc.. except, with several 100 of them created in this way, am I likely to cause memory problems - I forget the correct name for it, but will all these non-ptr variables be created on the heap? eventually filling it up (I''d guess there could be ~500bytes). In which case I''d normally think of using pointers... except that the ptr itself is 32bits (dependent on the OS of course), which in theory doesn''t seem to offer any useful savings.. any thoughts? Jack
<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ |
Hamster
Hamster
The only thing I can think of suggesting is making those variables public parts of a class. Then you could either make that class a singleton or have them as static variables (or both, really).

Following the singleton route, you should then be able to control creation and destruction:

int main()
{
GlobalVariableContainer *gvc = new GlobalVariableContainer;
//anything that might access the global variable container
delete gvc;
}

Admittedly the singleton would be a little dirty, having to allow public constructors, but the Enginuity articles by Richard Fine provide a useful little template for this kind of thing. The above example would force the creation of that memory on the heap, and only one pointer would be used. To access a variable from any file with the header included, you would then use something like:

int i = GlobalVariableContainer::Get().some_variable;

Admittedly, this means acquiring a reference everytime you want to access a variable, but if it gets called often enough then I think the cpu should cache it anyway, and the chances are compilers might have some optimisation wizardry to help with this kind of thing.

Be warned, I''m self taught, and have a very blundering "if it works, keep doing it" approach, so all of the above may be complete nonsense. Good luck in any case.
antareus
antareus
Singleton is overkill as is using pointers. Just use the easiest thing now and if it breaks you''ll have to change it later. But if you''re having to make hundreds of variables public then you have some design issues to say the least.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
PlayGGY
PlayGGY
quote:
Original post by antareus
Singleton is overkill as is using pointers. Just use the easiest thing now and if it breaks you''ll have to change it later. But if you''re having to make hundreds of variables public then you have some design issues to say the least.


Yeah, but I don''t think the person that was suggesting singletons was really saying you should use them.

And the rockets' red glare, the bombs bursting in air,gave proof through the fight that our flag was still there.Oh say, does that star-spangled banner yet waveover the land of the free and the home of the brave?
jollyjeffers
jollyjeffers
thanks for the thoughts,

quote:
The only thing I can think of suggesting is making those variables public parts of a class

Thats the only thing I''ve come up with so far although the singleton thing might be a step further than I was working on...


quote:
But if you''re having to make hundreds of variables public then you have some design issues to say the least.

I''m well aware that it aint clean design, and really aint my choice... but its carrying on from another programmer working in another language, I can only make do with what I''m given

Jack
<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ |

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.