C++ Singleton design question.

Question

I have a requirement to have a only a single instance of a class at any given point of time. Singleton is the obvious candidate. But I have some other conditions that are not typical of a Singleton.

1. The lifetime of the singleton is not the lifetime of the program. This object has to be created every time I enter a particular state and destroyed when I leave the state. For the entire duration of the state, I cannot create another instance of the class.
2. Every time, I enter the state and create a new instance, I need to pass a variable to the singleton. Its a number, based on user selection.

So my implementation has the following static functions -

// To be called exactly once, everytime I enter the state
void MySingleton::CreateInstance(size_t count);

// To be called any no. of times during the state
MySingleton * MySingleton::GetInstance();   

// To be called exactly once, when leaving the state.
void MySingleton::DestroyInstance();        

Now this implementation is a major detour from conventional singleton implementation.

Is there any problem with such implementation?

Are there any better alternatives?

Answer 1

If you create an instance every time you enter a given state and destroy it every time you leave that state, it would make more sense to have the instance be owned by whatever is managing state transitions (or some other entity that is aware of the state transitions).

For example, you could have a smart pointer to an instance as a member variable of the state manager. When you transition into the state you can initialize it to a new instance and when you transition out of the state you can destroy that instance.

In my opinion, this would be cleaner than and preferable to using the singleton design (anti-)pattern.

Answer 2

I think this solution is expensive in performance time. I'd create exactly one instance, and change the creation function to:

void MySingleton::reset(size_t count);

Answer 3

Is there any problem with such implementation?

Yep. The problem is that this is not a Singleton, because it is not what the "Singleton" pattern is all about. It's a simple variable, local to that state which you enter and leave.

Actually Singletons are just glorified globals, alive throughout the application's lifetime and should be prevented whenever possible anyway. Your "Singleton" isn't a global, it's a state-local.

Answer 4

The concept you are describing could be ensured by a class like this:

template<class Guarded>
class single_instance : private boost::noncopyable {
   static bool alive;
public:
   single_instance() {
      if (alive)
         throw std::runtime_error("instance already exists");
      alive = true;
   }
   ~single_instance() {
      alive = false;
   }
};

template<class Guarded>
bool single_instance<Guarded>::alive = false;

If you derive your class from this, it will be ensured that you can always only create one instance at a time:

class myclass : single_instance<myclass> {
public:
   myclass(size_t count);
   ...
};

You can now implement and instantiate myclass like a normal class, without the need for factory functions and getInstance methods. Trying to instantiate a second copy before the first one is destroyed will throw an exception.

Answer 5

If it's one-per-state, then make it from within your state object and make the constructor private, friend state.

Answer 6

I fully agree with "Singleton is just another form of global" and it should be avoided.

If your boss is insisting, you can try something like this:

class MyUtil
{
protceted:
 static MyUtil* m_Singleton = NULL;
public:
 /// Create the singleton if does not exists.
 /// \retun the singleton for this class.
 static GetSingleton()
 {
  if( !m_Singleton  )
   m_Singleton  = mew MyUtil();
  return m_Singleton ;
 }

 /// release singleton instance
 /// Warning: Multi-threading not supported.
 void StateRelease( void )
 {
  m_Singleton  = NULL;
  deleet this;
 }

};