#### Archived

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

# Another form of singleton pattern?

This topic is 5241 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I''ve seen lots of people, that dislike singletons here. I think, the main idea, why do they hate them, is because, you need to call "if" (resp. "cmp ..., ... je ...", or simillar), and thus they are slow. Well... what about this?:
singleton.h:

class Singleton {
public:
static Singleton *instance () { return inst; }
...
private:
Singleton () {}
Singleton (const Singleton &) {}
static Singleton *inst;
...
};

singleton.cpp:

#include "singleton.h"

Singleton *Singleton::inst = new Singleton;

...

And, of course, later - delete Singleton::instance ();


This solves the problem with the comparing the pointer against zero... I don''t know if there is (not) another problem with it... Can you tell me your opinion about this? Oxyd --- Unreadable code is code written on a piece of paper, but not the one, in which its programmer is using a space in place you don''''t.

##### Share on other sites
You''re reintroducing the problem the singleton pattern is supposed to solve - namely that C/C++ gives no guarantee of the order of initialisation of non-local static objects.

Example:
class Boom{	public:		Boom()		{			Singleton::instance()->function();		}	private:		static Boom* boom;};Boom* Boom::boom = new Boom();

What happens if boom gets initialised before your singleton instance?

Enigma

##### Share on other sites

class Boom {public:  void f () { ... }private:    Boom ()   {    f ();  }  static Boom *boom;};Boom *Boom::boom = new Boom;

I don't know if you meant exactly this, did you?

Oxyd

---
Unreadable code is code written on a piece of paper, but not the one, in which its programmer is using a space in place you don''t.

[edited by - Oxyd on January 16, 2004 2:59:32 PM]

##### Share on other sites
the main issue with singletons is not performance. performance is never the first major issue.

the main issue with singletons is that they get in general just abused by newbies (and even non-newbies) to hide the fact that they have no clue how to organise their stuff. so they put everything into different monolythic singletons that have full access to each other all the time.

If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

##### Share on other sites
No, I meant what I posted. The problem occurs when you have more than one static (in my example - your singleton and my boom).

1. C/C++ makes no guarantee in which order they are initialised.
2. My boom needs a guarantee that your singleton will be initialised before my boom is.

Sometimes the code will work, sometimes it won''t. This will probably be compiler specific. E.g. I think the Borland compiler initialises in the order that the statics are seen, i.e. bcc32 Singleton.cpp Boom.cpp will work and bcc32 Boom.cpp Singleton.cpp won''t. Another compiler might chose to initialise them alphabetically, or based on a hashcode, or randomly, or by the number of vowels in their name, or by...

Enigma

##### Share on other sites
quote:
Original post by davepermen
the main issue with singletons is not performance. performance is never the first major issue.

the main issue with singletons is that they get in general just abused by newbies (and even non-newbies) to hide the fact that they have no clue how to organise their stuff. so they put everything into different monolythic singletons that have full access to each other all the time.

But you have to have some organization in your code - I programmed in QBasic and even if the QBasic supports method, I didn't use them - that was total anarchy . So - how do YOU organize your code?

Oxyd

---
Unreadable code is code written on a piece of paper, but not the one, in which its programmer is using a space in place you don''t.

[edited by - Oxyd on January 17, 2004 11:35:34 AM]

• 40
• 15
• 10
• 23
• 10