Jump to content
  • Advertisement
Sign in to follow this  
THACO

Singleton

This topic is 4815 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 have what I believe is a correctly setup signleton. Now I want to use it in multiple source files. I know how to do it in two different ways. 1. extern CLog *LOG; //This way everywhere i can use LOG 2. CLog *LevelLOG = CLog::Instance(); // Here each source file needs to have own variable name I like only using LOG but is it bad to use extern? -THACO

Share this post


Link to post
Share on other sites
Advertisement
With a singleton all you should have to do is include the header file in any files that want to use it. Then get an instance in that file.

This works with a singleton that looks like this:



#ifndef _SINGLETON_H_
#define _SINGLETON_H_

class singleton
{
private:
singleton() {};
~singleton() { if ( pSing ) delete pSing; };

static singleton* pSing;
static bool made;

public:
static singleton& Get_Instance()
{
if (made == false)
pSing = new singleton;

return *pSing;
}
};

singleton* singleton::pSing;
bool singleton::made;

#endif




Simple get an instance wherever you need to.

Hope that helps bud,

ace

Share this post


Link to post
Share on other sites
Well yea, the singleton doesn't seem to be the problem, I am more asking what is a better way to get the instance

1. extern CLog *LOG; //This way everywhere i can use LOG
or
2. CLog *LevelLOG = CLog::Instance(); // Here each source file needs to have own variable name

-THACO

Share this post


Link to post
Share on other sites
Well i personally don't fabour the use of extern. If your files are class header files then simple have a member variable to store the instance, if they are plain C .C files then i would use the latter option.

ace

Share this post


Link to post
Share on other sites
You can do a couple things here.

1) Have your class return a smart_ptr to the singleton instance (so nobody is tempted to delete it)

2) Just use static member functions and invoke them like this

YourLoggingClassName::log("whatever");

the implementation would be something like:


// a static member function
void YourLoggingClassName::log(const char *string)
{
if(_instance) _instance->_log(string); // where "_log()" was a non-static function
}


The instance ptr would (of course) need to be static, for both cases to work.

In your main program source file, you can forward declare the static instance... or in another cpp file

YourClassName *YourClassName::_instance = 0;

Make sure that in your constructor, if "_instance" isn't already defined, you assign it to "this"... and if it is already assigned, you may want to throw an exception.


Just some ideas for you.

Share this post


Link to post
Share on other sites
I use a pretty system for handling singleton, check this:

template<class T>
class SubSystem
{
public:

static T& Instance()
{
static T Singleton;
return Singleton;
}

virtual void LoadConfiguration(const Configuration& Config) = 0;
virtual void Initialize() = 0;
virtual void Shutdown() = 0;
//details omitted
};


in this way you use the functionality of C that is related to static local function variable initialization (initialized the first time the code run at that point. When I need a singleton use I write this (example, the AudioSystem is a singleton that access FileSystem that is also a singleton):

class AudioSystem :
public SubSystem<AudioSystem>,
{
//SubSystem
ConfigurationSystem& ConfigurationSystem;
NotificationSystem& NotificationSystem;
FileSystem& FileSystem;

public:

AudioSystem::AudioSystem() :,
ConfigurationSystem(ConfigurationSystem::Instance()),
{ }
//details omitted
};


et voilà you have full access to the singleton that will be instanciated only if needed. This is (in my opinion) the fastest a most beautiful way to handle this.

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!