// Screen.h file
class Screen
{
};
extern Screen* const &ScreenPtr;
// Screen.cpp file
Screen *RealInstance = NULL;
Screen* const &ScreenPtr = RealInstance;
extern ClassName* const &InterfaceName ?
Author
I'm trying to find a decent way to allow access to an engine-type class without leaving the pointer globally accessable to modification. Here is an example of my best solution:
The screen.cpp file is free to allocate and destroy the real instance memory, but other modules are hidden from this privilege, correct? And the reference is protected from any modification, with the const setting, right?
Is this a bad way to do this? I'm trying to avoid the whole GetInstance()->DoSomething() deal, mainly because I think it just confuses things and looks very ugly. I would appreciate any ideas on how this can backfire on me, or any problems down the road that I cannot predict. Is there any reason this is a bad design?
Also, are there any performance issues with this? Accessing a reference is no different than accessing it's actual pointer, correct? It doesn't have to do two address lookups or anything, right?
Thanks for any help.
i don't understand why you have a defereferncing (sp?) operator and a address-of operator. wouldn't they cancel each other out?
shouldn't you just have: Screen const &ScreenRef = RealInstance ?
shouldn't you just have: Screen const &ScreenRef = RealInstance ?
Well, your declaration needs to be atleast a const class* to prevent delete being called on it, because delete doesn't change the value of the pointer, but the object pointed to. So you probably want const screen* const, which will obviously prevent you calling some member functions, etc. Now you're back at the start.
Author
Damn, you're totally right. So it protects against everything except delete? I guess it is very difficult to accidently call delete on such things, and delete can even be called on a GetInstance() type return value, right? The only way I can see to totally protect it is to find a way to avoid the use of a pointer altogether. Is that possible?
Alpha_ProgDes -> How can I allocate the instance dynamically and have a reference to the actual allocation memory?
Alpha_ProgDes -> How can I allocate the instance dynamically and have a reference to the actual allocation memory?
Quote:Original post by Jiia
Damn, you're totally right. So it protects against everything except delete? I guess it is very difficult to accidently call delete on such things, and delete can even be called on a GetInstance() type return value, right? The only way I can see to totally protect it is to find a way to avoid the use of a pointer altogether. Is that possible?
Couldn't you just make the class's destructor private?
Seems to bring protection to ridicilous levels though, so I'd suggest that you find a simple solution. Or you could just skip the protection completely, there's generally so many other (and much more common) mistakes you can make if you don't know the library that I don't think you should spend much time on idiot-proofing this one.
Author
You're saying I should drop the whole thing and just declare the pointer as normal extern? Or I should just not bother protecting it from being deleted?
I would like to at least protect it from being altered by misc typos. Something stupid and simple, such as if(Screen = NULL) OuchThatHurts().
Thanks for the suggestion.
I would like to at least protect it from being altered by misc typos. Something stupid and simple, such as if(Screen = NULL) OuchThatHurts().
Thanks for the suggestion.
Author
Doesn't that have the same flaw, though? The ability to delete the pointer memory from the accessor function?
It's just a personal thing I have againt accessors and instances. For a class instance, I can deal with it. But a global instance, it just seems very ugly to me. GetClass()->RunMethod(). If I make an accessor function, I'd probably declare a macro to remove the Get and () from it anyways.
That doesn't mean I won't use it. I'd just rather not. Would using a const reference be considered a less-attractive method?
It's just a personal thing I have againt accessors and instances. For a class instance, I can deal with it. But a global instance, it just seems very ugly to me. GetClass()->RunMethod(). If I make an accessor function, I'd probably declare a macro to remove the Get and () from it anyways.
That doesn't mean I won't use it. I'd just rather not. Would using a const reference be considered a less-attractive method?
Protecting a dynamic object from being deleted is something you won't be able to do, and rightly so. Ordinarily, you would overload the operator privately, or just not define it, but since you are using new, you need delete.
Seriously, you're making a mountain out of a mole hill. Only malicious coders would delete the variable to begin with. The 'correct' design pattern would, IMHO, not rely on globals to begin with, so cast your doubts into the void and continue the good battle. [wink]
Seriously, you're making a mountain out of a mole hill. Only malicious coders would delete the variable to begin with. The 'correct' design pattern would, IMHO, not rely on globals to begin with, so cast your doubts into the void and continue the good battle. [wink]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
