Quote:Original post by nullsquared
GAME can't be "potentially" large - either it's large, or it's not. If it's large, put it on the heap. If it's not, put it on the stack.
Its true that its size is a known quantity, but there's no good reason to put it on the heap.
My system works the same exact way. My main function consists of creating a mutex object (if this fails, I know an instance of my app is already running and I shut down), Creating/Initializing my application object, and kicking off my main loop by calling a method on my application object. It returns an int, which is the code to be returned by main.
For all intents and purposes this is a style thing --
Since, under this scenario, it is unlikely that a global instance of Game would be exported to any other code (in fact, its highly unlikely that there would even be a "main.h" file, let alone that you would extern the global instance), and all work essentially takes place under Game, the usual worries of global mutable state are minimized if not non-existent. The only real drawback to a global in this instance is that you give up precise control of when the Game instance is created or destroyed. All you know is that it is created "some time" before main() is entered, and destroyed "some time" after main is exited -- in most circumstances, you don't need to know any more than this. I believe the object will exist in the data segment under this scenario.
Next up is creating it on the stack -- here, the semantics (that is, reference rather than pointer) stay the same, without having the object in the global name space at all. The only real difference is that you now know that the object is created "as" the main function is entered, and it is destroyed "as" the function is exited. Pretty much the same, for all practical purposes, as a non-exported global instance. The object will exist on the stack in this scenario.
As a short aside, you could create a static local instance of game, which would IIRC, allocate storage in the data segment. Under this scenario, the name of the instance would not be available to the global namespace, and the object would be constructed on the initial call to main(), and destroyed some time after main is exited, similar to a global.
Lastly, you can create a new object on the heap by new'ing one up. You'll end up with pointer semantics, so you'll have to dereference before calling member functions, though you only call the main loop function (and possibly some init/shutdown member functions), so its not like the extra characters will kill you. The one, potentially big, thing you gain is exact control over the time of the object's construction/destruction -- this could be useful I suppose, but I have a hard time thinking of any scenarios which wouldn't be better served by appropriate use of other means.
I really don't think there's any
strong argument for one approach over any of the others. Personally, my objects are created on the stack because it has easier semantics than creating on the heap via new, and I don't have a need to precisely control the time of construction/destruction. I prefer stack instances over global instances simply because going global gains nothing (and as I explained, doesn't really loose anything practical either) -- this really goes back the the general rule of thumb that instances should be created on the stack unless there's a good reason to make them global instead.
