C++ Trick
Yes, a very BAD design issue. If you're using a null pointer to indicate that something is unavailable, you need to redesign, badly.
Author
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.
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.
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) } }
Author
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.
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?
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. :\
Author
Quote:Original post by JohnBoltonQuote: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.
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?
Quote:Original post by Telastynvoid 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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
