I''m, having trouble knowing when and how to use singletons and how they work. I mean, just because I''m using a class which points to itself doesn''t stop me from initializing like 3 different singletons of the same class. (Or have I misunderstood things?)

I think some people here are confusing singletons with header inclusion issues? Why? They have nothing to do with eachother.

Singletons are useful, but ONLY if what you are making is TRULY a singleton. IE, if you are just throwing a bunch of what would otherwise be global variables into a singleton so you can say you''re "Object Oriented" you''re being stupid.

What is a good use of a singleton? For instance a memory managment class. Most likely you would like to only have one of these for you''re entire program.

Also, if their is some piece of HW that it is only possible to have one of, a singleton would be very useful.

Tony

#ifndef __foo_h_
#define __foo_h_

class foo
{
public:
foo* GetInstance(); // Need a foo? Call this. It will only create one.
~foo();
private:
foo(); // Note, private ctor, only foo members can call this.
static foo* m_instance;
};

#endif


CPP FILE

#include "foo.h"

foo* foo::m_instance = NULL;

foo* foo::GetInstance()
{
if( m_instance == NULL )
m_instance = new foo;

return m_instance;
}

Oops... Should be static foo* GetInstance()

static foo* GetInstance();


Tony

quote:

---

Original post by iaretony
I think some people here are confusing singletons with header inclusion issues? Why? They have nothing to do with eachother.

---

I feel that''s directed at me. Yes, they can be related because you can have many singletons in your program and they act just like global variables (scope: entire application). Global variables, again, can lead to dependency issues between header files, especially if your headers aren''t properly formatted (no proper #ifndef-#define HDRNAME statements for instance).

quote:

---

Singletons are useful, but ONLY if what you are making is TRULY a singleton. IE, if you are just throwing a bunch of what would otherwise be global variables into a singleton so you can say you''re "Object Oriented" you''re being stupid.

---

It''s called encapsulation - read my first post.

In a nutshell: singletons are regular classes that you want only to have one instance of. For example(as mentioned above): level, renderdevice, soundmanager, etc. These are in no way different than your usual projectile class which has it speed, direction and some other variables, but is usually declared in numbers as a weapon can be fired many times. What I said, is that you can solve the problem of making (for instance) the Level and Camera classes available to all modules in the program in one of the following ways:

//SOLUTION 1://camera.h - suppose there''s only one camera in your gameclass Camera {}extern Camera* Cam;//level.hclass Level {}extern Level* Lev;//main.cpp#include "Camera.h"#include "Level.h"Camera* Cam;Level* Lev;main(){Cam = new Camera;Lev = new Level;}

//SOLUTION 2://camera.h - suppose there''s only one camera in your gameclass Camera {}//level.hclass Level {}//externs.hextern Camera* Cam;extern Level* Lev;//main.cpp#include "Externs.h"Camera* Cam;Level* Lev;main(){Cam = new Camera;Lev = new Level;}

Both solutions are equivalent, but the latter can end up causing dependency problems because you''re only human and will most likely include externs.h AND camera.h or level.h. Once you have many header (and singletons) files you won''t really be able to tell what''s going on without going through a lot of code each time you get a warning/error. By malformatting one of your headers or creating a mangled mess that your compiler can''t chew through, you''ll end up getting weird compiler errors. I had this problem recently so I would know. It took me several hours to sort out the mess. It''s as simple as that.

What AP suggested is that you do the following:

//camera.h - suppose there''s only one camera in your gameclass Camera {}//level.hclass Level {}//kernel.h#include "Camera.h"#include "Level.h"class Kernel{Camera* Cam;Level* Lev;}extern Kernel* Ker;//main.cpp#include "kernel.h"Kernel* Ker;main(){Ker = new Kernel;}

That way you''ll end up with only one singleton, but can have many classes in the program that are singletons by nature (there''s only one copy of them), but are not global (instead they''re accesible through the global class Kernel).

>> I mean, just because I''m using a class which points to itself doesn''t stop me from initializing like 3 different singletons of the same class.

Yes, you can, but in that case the singeltonian approach simply loses its meaning.

Does this explain things to you? Singletons are for the reasons I described above, considered an advanced topic - in essence, though, they''re nothing more complex than your average class Joe.

quote:

---

Original post by iaretony
#ifndef __foo_h_
#define __foo_h_

---

A friendly warning: do not create identifiers with underscores, not ever. Identifiers/variable names/what not beginning with one or two underscores (creating one with more would be an atorcity ) are reserved, as stated in the C++ standard (can''t quote it, sorry). The only thing that offically ignores this rule (that I know of), is VC, which rather uncaringly defines header guards with leading underscores. It is advised that you don''t. While this won''t most likely lead to any error reports, if it does, you''ll have the time of your life debigging your program.

Thats always been one of my conventions... the dual leading underscores thing...

#ifndef __FOO_H__
#define __FOO_H__
..
#endif

While you do occasionally run into reserved words with leading underscores, you VERY rarely see them with trailing underscores as well....

but hey, if its standard, guess i cant argue with that

Singletons and other useful constructs are in the "Gang of four" Design Patterns book, if you want a definitive reference. Basically what a singleton does, is makes sure that you only have one instance of the class that you coded into a singleton. It works by having a reference to a space in memory, where the one instance of the program is in, this is created by a private constructor, so that nobody else can access it, other than the getInstance() method. Only use if you need the strict enforcement of having one instance of a class, otherwise it is just painful to deal with.