Original Post
🔒 Locked
Easy question for you experienced programmers.
Advertisement
If it''s just a global object, not a pointer to an object then both it''s constructor and destructor will be called at program start time and termination respectively so the answer is yes.
If it is a pointer then naturally you still retain the responsibility to explicitly call new and delete yourself to achieve the same effect.
Bear in mind though, that for a simple global object where the constructor and destructor are called on your behalf, you have no idea in what order amongst other global objects it will be instantiated and this can cause you a problem if your global objects rely on each other being instantiated in a certain order. It can be a better strategy to always retain this control over anything global.
If it is a pointer then naturally you still retain the responsibility to explicitly call new and delete yourself to achieve the same effect.
Bear in mind though, that for a simple global object where the constructor and destructor are called on your behalf, you have no idea in what order amongst other global objects it will be instantiated and this can cause you a problem if your global objects rely on each other being instantiated in a certain order. It can be a better strategy to always retain this control over anything global.
invective - because that increases code size and compile time, and decreases the speed of the startup and shutdown of the program. Not by much, sure, but the alternative still wins: declare the class instance, just not as a pointer!
BeerHunter - code size and compile time increase by making the global a pointer? I''m not sure about how significant that would be. The object is still there and needs to be compiled.
Yes there is extra code at startup/shutdown to create/destroy the object, but it isn''t that much in terms of size or compile time.
as far as app startup/shutdown - the ctor of the global object has to be executed at startup regardless of whether it is automatic or as a result of new MyGlobal.
So you are still paying the cost for the construction of that object at app startup.
Like the anonymous poster quoted - the biggest problem with doing it via just the straight global object is you do not have control over the order of construction/destruction of those objects.
When it''s one object its not a problem, but once you have a dozen objects which may have construction order dependencies then there are problems.
using a Singleton pattern and a lazy evaluation approach to construction, eg construct the object on the first access - will help aleviate those problems and actually will speed up initial program startup - although you will eventually have to pay the cost of constructing the object.
Yes there is extra code at startup/shutdown to create/destroy the object, but it isn''t that much in terms of size or compile time.
as far as app startup/shutdown - the ctor of the global object has to be executed at startup regardless of whether it is automatic or as a result of new MyGlobal.
So you are still paying the cost for the construction of that object at app startup.
Like the anonymous poster quoted - the biggest problem with doing it via just the straight global object is you do not have control over the order of construction/destruction of those objects.
When it''s one object its not a problem, but once you have a dozen objects which may have construction order dependencies then there are problems.
using a Singleton pattern and a lazy evaluation approach to construction, eg construct the object on the first access - will help aleviate those problems and actually will speed up initial program startup - although you will eventually have to pay the cost of constructing the object.
quote:
Original post by Anonymous Poster
Bear in mind though, that for a simple global object where the constructor and destructor are called on your behalf, you have no idea in what order amongst other global objects it will be instantiated and this can cause you a problem if your global objects rely on each other being instantiated in a certain order. It can be a better strategy to always retain this control over anything global.
----response----
One way to have an elegant workout of this problem is by using the singleton pattern instead of global variables. Using Singleton, you gain the control of object instantiation, and it will be automatically be destructed when the program exits.
That may solve the problem, but only if you make it a singleton in a very specific way:
http://www.gamedev.net/community/forums/topic.asp?topic_id=67884
Even if you use singletons, if you implement them by having a static instance of the class as a member and if you have more than one, there is no guarantee that one will be initialized before the other.
A solution is to have the singleton GetInstance function return a reference to a function-local static. This assures that statics are initialized when they are referenced. If you do it this way, the object is also destroyed at the end of the program, but it is not created until the GetInstance function is called.
Edited by - Stoffel on November 28, 2001 1:04:14 PM
dtome:
Well a global class could be used for many things the obvious one is a GFXManager...
but hey that''s useless...
Well a global class could be used for many things the obvious one is a GFXManager...
but hey that''s useless...
quote:
Original post by dtome
Jest a quick quesiton......
WHY would you want to declare a GLOBAL class? This does not seem appropriate for OOP, but this is only my opinion.
--Tome
Games are dreams of reality!
Global classes can affect reentrancy , which is a significant design decision, but OOP != reentrancy (and vice versa), at least not to anybody I know.
Like the anonymous poster pointer out I too agree that the singleton pattern is the better way to go. Then, pass a pointer of this class to anyone who _needs_ it from startup.
Managing scope is one of your best tools for maintaining and debugging source. Once you introduce too many global variabes you increase the likelihood of confusion and changes in one place could inadvertently affect other places.
I too have a graphics manager but it is a singleton and only the classes that need to display graphics know who this manager is. Sometimes one protects parts of one''s source from other parts. By designing with a singleton you enforce programmers to design their components correctly rather than allowing them to quickly grab whatever data they want. Remember, faster to code != better design in most cases.
RandomTask
Managing scope is one of your best tools for maintaining and debugging source. Once you introduce too many global variabes you increase the likelihood of confusion and changes in one place could inadvertently affect other places.
I too have a graphics manager but it is a singleton and only the classes that need to display graphics know who this manager is. Sometimes one protects parts of one''s source from other parts. By designing with a singleton you enforce programmers to design their components correctly rather than allowing them to quickly grab whatever data they want. Remember, faster to code != better design in most cases.
RandomTask
Global classes usually mean there is a single instance.
In which case you have a Singleton ( a class where you want to have a single instance and a centralized access to it - very much like a global )
This is pretty common - e.g. the one class that abstracts the DirectSound interface or other cases for single instance object patterns.
maybe an undo manager?
this happens a lot more than one would think.
Although maybe it is a case of poor OOD, but it does seem to be a common pattern.
the function static solution for the singleton GetInstance() definately works, however, it does have some limitations - such as if you wanted to be able to subclass and control which exact singleton object was instantiated.
For example, maybe you have a singleton factory class that makes windowing elements - different platforms may subclass the factory class to make the platform specific classes.
but it depends on the situation - sometimes the function static approach will work ok.
However, you still have the problem of no control over the order of destruction at application exit.
In which case you have a Singleton ( a class where you want to have a single instance and a centralized access to it - very much like a global )
This is pretty common - e.g. the one class that abstracts the DirectSound interface or other cases for single instance object patterns.
maybe an undo manager?
this happens a lot more than one would think.
Although maybe it is a case of poor OOD, but it does seem to be a common pattern.
the function static solution for the singleton GetInstance() definately works, however, it does have some limitations - such as if you wanted to be able to subclass and control which exact singleton object was instantiated.
For example, maybe you have a singleton factory class that makes windowing elements - different platforms may subclass the factory class to make the platform specific classes.
but it depends on the situation - sometimes the function static approach will work ok.
However, you still have the problem of no control over the order of destruction at application exit.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement