Another form of singleton pattern?

Started by
4 comments, last by Oxyd 20 years, 3 months ago
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.
Advertisement
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
What about this:

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]
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
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

My Page davepermen.net | My Music on Bandcamp and on Soundcloud

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
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]

This topic is closed to new replies.

Advertisement