Archived

This topic is now archived and is closed to further replies.

the_recon

Singletons

Recommended Posts

Crispy    556
pros: encapsulation (you encapsulate a bunch of otherwise global variables)

cons: interdependability between modules - you''ll have to choose between:

  • creating something like externs.h, which includes all necessary headers (this can lead to dependency problems)
  • adding the extern declaration of the singleton class to the respective headers which isn''t always feasible and would lead to the fact that you have to include many headers in a cpp file to have access to all of the classes. Failing to include all necessary headers can also lead to declaring the "singleton" locally.

    You should try to avoid singletons where ever possible. For instance, the ultimate solution would be wrapping everything in one global class, though that''s almost never a good idea. In an opengl application, keep only the most vital classes as singletons: level, camera (possibly a part of the level), renderer, window etc. Wrap as much as is reasonable, at the same time trying maintain simplicity and efficiency in your project.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
I''d suggest using only one singleton (if you have to. I do use this myself, even though I''m not too fond of the idea)... A "kernel" for your app if you will. Then just have all your other objects and variables (like your level, window, renderer etc) as members of this kernel class. That way it''s all neat and tidy and you can access everything from anywhere.

i.e. Kernel::Get().GetLevel() etc

Share this post


Link to post
Share on other sites
TerraX    180
I''ve only just discovered singletons... and I''ve gone mad with ''em!

I have the following classed as singletons...
CWindow (Window stuff)
CScreen (Err, screen stuff (OGL setup etc)
CLog (Only on log file needed afterall!)
CTexMan (Only one texture manager needed!)
CConsole (Only one console window needed!
CMoreOfEm? (Maybe more,I can''t remember)


I''m kinda getting scared by what the people above have said, how come ya don;t use singletons more?
(I guess I''ll find out in a couple of months or so)

Is it that, the whole project gets kinda "mystified", I mean like, "I wonder if this instance is being created now, or then)

Hmmm, no problems so far, singletons are my saviour, but I still need to learn much.

Download some source: http://www.DavesProgramming.com

Share this post


Link to post
Share on other sites
CaptainJester    523
another pro: not having to pass references up the whazoo. Especially with screen objects that are being drawn to.



First make it work,
then make it fast.

--Brian Kernighan

"I’m happy to share what I can, because I’m in it for the love of programming. The Ferraris are just gravy, honest!" --John Carmack: Forward to Graphics Programming Black Book

Share this post


Link to post
Share on other sites
the_recon    114
I am using 2 kinds of singletons mostly (am cautious)

the PPTEXTUREMANAGER and another one for vertexbuffers.
They are generally just a list of stuff and functions and store their data in hash tables. (Oh! And they''re singletons too)


I just don''t unserstand why I should avoid them. I mean, some people say that I should use templates as much as I can while others thinks they''re up to no good at all. I''m ery confused about what to use and what not to use since everyone have different opinions about this matter.

Share this post


Link to post
Share on other sites
Lukerd    122
I only heard about singletons the other day, when reading an article somewhere (maybe Gamedev) on making a Texture Manager. Can somebody point me towards a decent tutorial on them?

Thx

Lukerd.

Hyperdev

"To err is human, to really mess up requires a computer"

Share this post


Link to post
Share on other sites
RamboBones    102
Head over to www.gametutorials.com the have an article that explains all you need to know about them.

Crisp: What kind if singletons are you using!?!? I''ve never experienced those sorts of problems your having and I use to overuse singletons like nothing. Maybe you should check out the page on gametutorials ti?



GDSAUBY GameDev Society For UnBanning YodaTheCoda
If you want to see yoda unbanned then put this in your sig

Share this post


Link to post
Share on other sites
the_recon    114
www.gamestutorials.com only gives you the source code. It doesn''t explain how things work. It only shows you how to make them work and it certainly never said when kt''s best to use singletons =/

Share this post


Link to post
Share on other sites
Crispy    556
quote:
Original post by RamboBones
Crisp: What kind if singletons are you using!?!? I''ve never experienced those sorts of problems your having and I use to overuse singletons like nothing. Maybe you should check out the page on gametutorials ti?



What do you mean by "what kind of singletons"? I just said that used to have a lot of interdependence because of singletons. And I know what singletons are and how they''re used, thank you very much. What AP suggested is feasible, but not to my taste - a program is a whole, further encapsulating everything in it into one class is not really to the way I''d do things.

the_recon: I can''t understand what the problem is? Do you have trouble understanding what singletons are or are you just cofused about where and how to use them and what kind of effects their use has on your source code?

Share this post


Link to post
Share on other sites
the_recon    114
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?)

Share this post


Link to post
Share on other sites
iaretony    127
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

Share this post


Link to post
Share on other sites
iaretony    127

#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;
}

Share this post


Link to post
Share on other sites
Crispy    556
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 game

class Camera {}

extern Camera* Cam;

//level.h

class 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 game

class Camera {}

//level.h

class Level {}

//externs.h

extern 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 game

class Camera {}

//level.h

class 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.

Share this post


Link to post
Share on other sites
Crispy    556
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.



Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
bastard2k5    238
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.

Share this post


Link to post
Share on other sites