Jump to content
  • Advertisement
Sign in to follow this  
JinJo

is there a way to get rid of clas::getSingleton().functionCall

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

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.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by JinJo
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.
If Log is a singleton, you probably shouldn't try to hide that fact from the user of the class.

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.

Share this post


Link to post
Share on other sites
Guest 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()

Share this post


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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
"...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.

Share this post


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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


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

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!