Jump to content
  • Advertisement
Sign in to follow this  
lukas78

context structure

This topic is 4402 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
You should be avoiding globals as much as possible really, it breaks encapsulation.
I tend to use singletons for global manager classes.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
You 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 lukas78
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.


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?

Share this post


Link to post
Share on other sites
Quote:
Original post by deffer
Quote:
Original post by Evil Steve
You 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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
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.


Uhm. With that form of using globals I would agree with you. Using
SomeManager g_SomeManager;
is plain dangerous.

What I meant from the beginning was:
SomeManager *g_pSomeManager = 0;

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
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.

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.

Share this post


Link to post
Share on other sites
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;
s64 objectsCount;

ptr<core::CMessageRouter> msgRouter;
ptr<core::CResourceMgr> resource;
config::CConfiguration conf;
}

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

Share this post


Link to post
Share on other sites
Quote:
Original post by lukas78
class 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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!