is there a way to get rid of clas::getSingleton().functionCall
Author
I was just wondering if there was a way to call functions from a singleton class without having to call getSingleton as part of the function call?
Say for example:
Log::GetSingleton().Write("log this or that");
well I have the log class a singleton so that it can be used anywhere in the program but I dont want to have to keep writing getSingleton or have to make the user aware that it is a singleton and frustrate them by having to type that all the time.
Quote:Original post by JinJoIf Log is a singleton, you probably shouldn't try to hide that fact from the user of the class.
I was just wondering if there was a way to call functions from a singleton class without having to call getSingleton as part of the function call?
Say for example:
Log::GetSingleton().Write("log this or that");
well I have the log class a singleton so that it can be used anywhere in the program but I dont want to have to keep writing getSingleton or have to make the user aware that it is a singleton and frustrate them by having to type that all the time.
You could shorten the function name to Get(), which might be a little more convenient. Or, you could use a different pattern or model, such as a monostate or a global object.
well Log::ref() and Log::ptr() dont take much writing but you could always define it in the header after the class.
Quote:
#define g_log Log::GetSingleton()
Quote:Original post by Anonymous Poster
well Log::ref() and Log::ptr() dont take much writing but you could always define it in the header after the class.Quote:
#define g_log Log::GetSingleton()
Sure. Why not. Let's pretend we are not using a global by using a singleton, then pretend we are not using a singleton by using a define. [smile]
I'd agree with jyk that a monostate approach might be suitable here. Equally, GetSingleton is a bit of a verbose name for the get method.
"...Let's pretend we are not using a global by using a singleton..."
That is not the purpose of a singleton, although I do agree that a monostate is a much better alternative.
That is not the purpose of a singleton, although I do agree that a monostate is a much better alternative.
I still don't really understand the advantage of using a singleton over a global. It doens't seem to me to be any different. Can anyone explain what the advantages are, because I feel I have a bit of a hole in my understanding.
I'm not actually convinced a monostate would really offer any advantages here either. If you only have one log, a singleton or monostate don't seem to be any better than a global. If you might need multiple logs in the future, the singleton or monostate become useless.
I'm probably missing something fundamental here.
I'm not actually convinced a monostate would really offer any advantages here either. If you only have one log, a singleton or monostate don't seem to be any better than a global. If you might need multiple logs in the future, the singleton or monostate become useless.
I'm probably missing something fundamental here.
I still don't really understand the advantage of using a singleton over a global.
A global is a global instance of which may it not be the only one, a singleton is a global instance of which there can only be one. Its a creation pattern which is abused.
A global is a global instance of which may it not be the only one, a singleton is a global instance of which there can only be one. Its a creation pattern which is abused.
Quote:Original post by EasilyConfused
I still don't really understand the advantage of using a singleton over a global. It doens't seem to me to be any different. Can anyone explain what the advantages are, because I feel I have a bit of a hole in my understanding.
Singletons give people a warm fuzzy feeling that they're using design patterns, and everyone knows that patterns are always good, right?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
