[diego_pmc]

Btw, here's an extra question that I don't personally know the answer to. Meyers' singleton although great for single threaded applications is completely unsuited for multi-threaded ones. I guess the alternative is to dynamically allocate the instance (like in Dark_Nexus' example). What methods are there to deallocate the memory if you choose to make a singleton where the instance is allocated dynamically?

[atraub]

Number 2 is a common question. If it blindsides you; you don't deserve the job. No matter what job you want, you gotta know who you're working for. The best answer is:

Quote

Meh, could be worse.

[shintetsu_80]

A singleton is design pattern where only one instance of that object exists during the lifetime of the application.

Singletons are useful for managing tasks that multiple objects need to share.

I've used this approach to reduce calls to binding textures and loading sounds. For example a texture manager would keep track of the currently bound texture so when you request a new texture from the texture manager the manager would know if it needed to bind a new texture or just hand back a handle to the currently bound texture. In this case any object that uses a texture is going to share from the same pool of textures. No need to take up space with multiple copies of the same texture.

Another useful implementation of a singleton would be a logger. Only one object needs to know how to log files and any object that needs to log something would just send it's log message to the logger.

Spoiler

template<class T>
class Singleton
{
	public:
		static inline T* Instance()
		{
			static T* inst;
			if (!inst)
				inst = new T;
				
			assert (inst != NULL);
			return inst;
		}
	
	protected:
		Singleton (void) {}
		Singleton (const Singleton&) {}
		Singleton& operator= (const Singleton&) {}
		~Singleton() {}
};

Another great question. This is one of my favorite topics.

[stayscrisp]

I really don't see how any problems could arise from having this implementation as a friend:

template<class T>
class Singleton
{
  public:
    static T* Instance()
    {
        // Meyers singleton
        static T obj;
        return &obj;
    }
};

Having it have access to the singleton class it is a friend of is exactly what you want it to do. All it really is is a way of saving you a little implementation and this is definitely a case where I would throw caution to the wind.

[shintetsu_80]

hype261, on 23 February 2011 - 07:05 AM, said:

shintetsu_80, on 22 February 2011 - 04:44 PM, said:

A singleton is design pattern where only one instance of that object exists during the lifetime of the application.

Singletons are useful for managing tasks that multiple objects need to share.

I've used this approach to reduce calls to binding textures and loading sounds. For example a texture manager would keep track of the currently bound texture so when you request a new texture from the texture manager the manager would know if it needed to bind a new texture or just hand back a handle to the currently bound texture. In this case any object that uses a texture is going to share from the same pool of textures. No need to take up space with multiple copies of the same texture.

Another useful implementation of a singleton would be a logger. Only one object needs to know how to log files and any object that needs to log something would just send it's log message to the logger.

Spoiler

template<class T>
class Singleton
{
	public:
		static inline T* Instance()
		{
			static T* inst;
			if (!inst)
				inst = new T;
				
			assert (inst != NULL);
			return inst;
		}
	
	protected:
		Singleton (void) {}
		Singleton (const Singleton&) {}
		Singleton& operator= (const Singleton&) {}
		~Singleton() {}
};

Another great question. This is one of my favorite topics.

Generally speaking you don't need the assert to ensure that memory was allocated with the new operator. If memory allocation fails then a bad_alloc error will be thrown. You can make the compiler return 0 on memory allocation failure by using std::nothrow

That's true and I did consider removing that from my sample but since I had just pulled it out of one of my old test projects I developed a while back to help myself understand singletons decided to leave it in.

I suppose the real question would be is it wrong or is it just a matter of coding preference?

[ButchDean]

I'm noticing on this thread that everyone is making life more difficult than need be to solve the problem. In a small section of isolated code it is fine to have your templated singletons with friend function, but in reality, in a very large code base like a modern game, you will want to keep things based on first principles. All these extra modifications do is complicate maintenance if employed, since their benefits are negligible to say the least. And I reckon that is why everyone is going round in circle on this thread.

[diego_pmc]

Still, I never got an explanation as to why templates are an improvement. I really don't understand this...

Spoiler

diego_pmc, on 22 February 2011 - 06:14 AM, said:

I think I'm not very clear about what I mean. Let me try through code. Why should I have this...

Spoiler

template<class T>
class Singleton
{
  public:
    static T* Instance()
    {
        static T obj;
        return &obj;
    }
};

class Foo
{
  friend Singleton;

  protected:
    Foo();
    Foo(const Foo& other);
    ~Foo();
    Foo& operator=(const Foo& other);
};

... instead of this...

Spoiler

class Foo
{
  public:
    static Foo* Instance();

  protected:
    Foo();
    Foo(const Foo& other);
    ~Foo();
    Foo& operator=(const Foo& other);
};

All I'm basically doing is removing the need to declare the Instance() function for every class with the need to include one more header (for the template) and to declare a friend.

diego_pmc, on 22 February 2011 - 08:53 AM, said:

What I'm saying is (to continue from my last post), are there any advantages to having a singleton template, instead of making each class a [singleton]? In the example you gave the Factory template could very well be a singleton itself so there's no need for the second typedef.

This post has been edited by diego_pmc: 23 February 2011 - 10:38 AM

[ButchDean]

diego_pmc, on 23 February 2011 - 05:27 PM, said:

Still, I never got an explanation as to why templates are an improvement.

That's because they aren't an improvement to the concept of a singleton. look at it this way, in a game you are only going to implement certain aspects of the game engine (UI, camera, IO, logging, etc.) as a singleton, and since you will be creating a class for them anyway you might as well implement the class as a singleton.

[dorknexus]

Dependency injection is the common and preferred way to avoid mucking with singletons. I don't think DI is very common with C or C++ however. In Java (using Guice) it's just as easy as adding or removing an @Singleton attribute from your class. Other classes which rely on your singleton never know the better.

[SixOfEleven]

Singleton can be quite useful. If any of you XNA/C# programmers that are reading this it is relatively painless to make a Singleton class with C#.

Spoiler

You can seal the class which automatically prevents other classes from inheriting from your class, thank you for that feature C#. Because the field is static the first time the class is referenced the instance is automatically created.

sealed class Singleton
{
    private static Singleton instance = new Singleton();

    public static Singleton Instance
    {
        get { return instance; }
    }

    private Singleton()
    {
    }
}