extern ClassName* const &InterfaceName ?

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

Recommended Posts

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:
// Screen.h file
class Screen
{
};
extern Screen* const &ScreenPtr;

// Screen.cpp file
Screen *RealInstance = NULL;
Screen* const &ScreenPtr = RealInstance;


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.

Share on other sites
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 ?

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

Share on other sites
Oh, and feel free to use references wherever.

Share on other sites
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?

Share on other sites
Quote:
 Original post by JiiaDamn, 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.

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

Share on other sites
Why not allow access to the pointer only through an accessor function?

Share on other sites
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?

Share on other sites
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. [I got carried away at the end...] [wink]

• 17
• 11
• 12
• 9
• 49
• Forum Statistics

• Total Topics
631395
• Total Posts
2999758
×