Jump to content
  • Advertisement
Sign in to follow this  
Telastyn

C++ Trick

This topic is 5433 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

Yes, a very BAD design issue. If you're using a null pointer to indicate that something is unavailable, you need to redesign, badly.

Share this post


Link to post
Share on other sites
Advertisement
Hrm. This might be a silly question, but to what?

Do others commonly have a little wrapper class that handles interface availability? Then the "avoid manager/handler classes" mantra around here seems to come into effect.

Do they effectively make the interface a prerequisite to the other classes? To me, missing a logging mechanism isn't a fatal error...

Do they attempt to create an unavailable interface each use [singletons]? That seems as though it would create a great amount of thrashing should the interface remain unavailable for some time.

Share this post


Link to post
Share on other sites
Just throwing out some ideas here:


static void SomeClass:UseMe( params ) {
// this is the "normal" way
if (i'm not available yet) { activate me; }

// might try...
if (i'm not available yet) {
load the required resource from another thread
or if it's a nice async deal and it doesn't hog
time while you wait, just:

put (params) onto some kind of processing queue

return; // (process things later when they get up and running)
}
}

Share this post


Link to post
Share on other sites
Quote:
Original post by C-Junkie
You could take the quake route and make the console ALWAYS there...


In my current project it actually does almost always exist. Except for the first 2-3 lines anyways, and I could easily make it everything. I actually don't use this in my current console. I just assume that the console exists and never test the pointer.

Share this post


Link to post
Share on other sites
Quote:
Original post by Washu
Yes, a very BAD design issue. If you're using a null pointer to indicate that something is unavailable, you need to redesign, badly.


Wait a second Washu. That is how a Singleton works -- you reference a Singleton, and if its pointer is null, it means that it doesn't exist and so it creates one.

Anyway Telastyn, you are basically implementing a Singleton in a way that is hackish and difficult to maintain. Why not just do it right?

Share this post


Link to post
Share on other sites
Urg. A static ("class") function is not supposed to require an instance for its operation. If you provide static console::newText, then people expect to be able to call console::newText as if it were just a free function. :\

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
Quote:
Original post by Washu
Yes, a very BAD design issue. If you're using a null pointer to indicate that something is unavailable, you need to redesign, badly.


Wait a second Washu. That is how a Singleton works -- you reference a Singleton, and if its pointer is null, it means that it doesn't exist and so it creates one.

Anyway Telastyn, you are basically implementing a Singleton in a way that is hackish and difficult to maintain. Why not just do it right?


I just rather recently realised that I could even do nullptr->stuff() without it causing things to explode.

I don't know, singletons to me seem to my admittedly limited perspective to be a 'clever trick' as you so describe it. They seem to be a slightly clumsy way for the programmer to ignore initialization procedure.

To me, I worry about the worst case. For singletons, this likely involves a situation like a file logger when the file cannot be created. Whenever a logging event occurs, it'll cause the entire app to thrash as it repreatedly tries to open the file for writing. For cases like that, I'd personally rather things fail more gracefully.

*sigh* unfortunately there's probably no better root reason than ignorance and stubbornness.

Share this post


Link to post
Share on other sites
Singletons do seem like a "trick" to me. They seem to be a trick to avoid having explicit global variables, yet still have that global variable availability. What am I missing?

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn


void console::newtext(char *intext){
//
//
//

if (!this){
return;
}
// otherwise proceed as normal
}


You're throwing away a precious control path. Excpetions aren't ideal either; they add copius amounts of control paths.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!