Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualMilcho

Posted 27 January 2013 - 12:37 PM

This isn't a singleton pattern.
A singleton is a class of which one and only one instance is allowed to exist. This is normally achieved by making the constructor, and the copy constructor private, and having a static function (usually named Instance() ) that returns the instance of that class (creating it if it doesn't exist), one version of which looks like this:
SomeClass* SomeClass::Instance(){  static SomeClass instance;  return &instance;}
You can just have the requirement that each of your states is initialized with a pointer to the player, which is what I do. Just create the player in whatever class owns/creates/manages each state, since it looks like you want the player to be persistent outside those states anyway. You don't even have to dynamically allocate the player, just make it a non-pointer class member of the class that manages your states.

#1Milcho

Posted 27 January 2013 - 12:35 PM

This isn't a singleton pattern.

A singleton is a class of which one and only one instance is allowed to exist. This is normally achieved by making the constructor, and the copy constructor private, and having a static function (usually named Instance() ) that returns the instance of that class (creating it if it doesn't exist), one version of which looks like this:

SomeClass& SomeClass::Instance()
{
  static SomeClass instance;
  return instance;
} 

You can just have the requirement that each of your states is initialized with a pointer to the player, which is what I do. Just create the player in whatever class owns/creates/manages each state, since it looks like you want the player to be persistent outside those states anyway. You don't even have to dynamically allocate the player, just make it a non-pointer class member of the class that manages your states.


PARTNERS