   context structure
  hey,I'm trying to implement in my application some kind of context structure. My goal is easy to explain - I want to keep objects, which should be global visible, in one place instead in whole application and declare as extern or something like that.When I declare context as global then I will have only one object which can act as a bridge for all global data.After few attempts I feel dissapointed. I expected that I achieve some clean and easy way to acess to global objects. But my context growing up very much, becouse almost all manager or controller in my appliaction should reside in that context. so my question are :first at all - what is the best practice to manage global objects ?does context a good way to do this ? should context be passed to methods as a argument or should be declared as global object ?best regards,lukasz   
  You should be avoiding globals as much as possible really, it breaks encapsulation.I tend to use singletons for global manager classes.   ;Quote:Original post by Evil SteveYou should be avoiding globals as much as possible really, it breaks encapsulation.I tend to use singletons for global manager classes.To be honest, I never really saw the difference.Quote:Original post by lukas78After few attempts I feel dissapointed. I expected that I achieve some clean and easy way to acess to global objects. But my context growing up very much, becouse almost all manager or controller in my appliaction should reside in that context.I'm using some sort of context structure. There are, like, four objects in there. So what do you got there that makes your context explode?   ;Quote:Original post by defferQuote:Original post by Evil SteveYou should be avoiding globals as much as possible really, it breaks encapsulation.I tend to use singletons for global manager classes.To be honest, I never really saw the difference.To be honest, there really is no difference.   ;  The advantage of singletons is you can control the order of construction and destruction. With globals you have no control, and the order of construction is pretty much random.   ;Quote:Original post by Evil SteveThe advantage of singletons is you can control the order of construction and destruction. With globals you have no control, and the order of construction is pretty much random.Uhm. With that form of using globals I would agree with you. UsingSomeManager g_SomeManager;is plain dangerous.What I meant from the beginning was:SomeManager *g_pSomeManager = 0;   ;Quote:Original post by Evil SteveThe advantage of singletons is you can control the order of construction and destruction. With globals you have no control, and the order of construction is pretty much random.This is the sole advantage, and it's not that much of an advantage, as code that depends on the order of construction/initialization of external objects is inherently hackish/pokey.The reason that globals and singletons are fundamentally indistinguishable is that they both fail to provide real access limitations; singletons must be "globally available" to a large subset of code, each object of which can obtain a reference and manipulate exposed members at will.Plus, singleton implementations are rarely thread-safe and reentrant.   ;  thank u for all responses.my Context structure is looking like below :(all member are public right now for simplify, please ignore this)class Context{public:   Context() {};   ~Context() {};   Statistics  stat;   HINSTANCE   hInstance;   ptr<core::CGfxApp> gfxApp;   ptr<gfx::CGfxApp> gfxDevice;   ptr<tool::CLoggerMgr>   logger;   core::CTimer globalTimer;   tool::CHashTable<IObject,512>htObject;   s64objectsCount;   ptr<core::CMessageRouter>msgRouter;   ptr<core::CResourceMgr>resource;   config::CConfigurationconf;}and I'm just at the begining. I'm afraid that this structure could be growing up if I won't change direction in projecting.I'm aware that I could redesign Context class in some ways, for example im able to divide resources into two group - one will keep gfx objects (like textures, vertex buffers) and second group will keep other resources (like loggers, open files, etc). The first one I could keep in CSceneMgr and other in CResourceMgr. Another example im seeing when im looking at htObject member (this member keeps information for all dynamically allocated objects, a bit before end of application im checking if i free all resources). I should keep it in CResourceMgr as well. Although I know that I'm at the begining of my project and I'm afraid that I can do too big mistake which will be hard to correct. Still I dont have implemented most of structures and objects yet - event mgr, gui mgr, vertex buffers, etc. EvilSteve, idea of singleton is usefull here I suppose. I think I will redesign and put Context as a singleton in main application object - gfxApp. I hope this will make easier to manage as well as make code much more readable.best regards,lukasz   ;Quote:Original post by lukas78class Context{ [...]}and I'm just at the begining. I'm afraid that this structure could be growing up if I won't change direction in projecting.This amount of members seems reasonable to me (except hInstance). I don't suppose it will be growing. I particularly don't have any more, uhm, managers, etc.IMO it's better to keep all globals under direct control than spread instances (extern'ed or singleton'ed, whatever) among multiple source files.   