ich möchte mehrere Klassen zu Singletons machen und jetzt frage ich mich, welches Design am schönsten ist und am wenigsten Probleme macht.
Mir schweben folgende 2 Ideen vor:

template <typename C>
 class Singleton
 {
 public:
    static C* instance ()
    {
       if (!_instance)
          _instance = new C ();
       return _instance;
    }
    virtual
    ~Singleton ()
    {
       _instance = 0;
    }
 private:
    static C* _instance;
protected:
    Singleton () { }
 };
 template <typename C> C* Singleton <C>::_instance = 0;

/* Verwendung */
 class Test : public Singleton <Test>
 {
 friend class Singleton <Test>;
 public:
    ~Test () { };
    static Test* instance ()
    {
       return Singleton <Test>::instance ();
    }
    void xyz () { }
 protected:
    Test () : Singleton <Test> () { }
 };
 Test::instance ()->xyz ();

Wenn ich nun eine Klasse T zum Singleton machen will, muss ich folgendes machen: von Singleton<T> ableiten, friend class Singleton<T> einfügen und alle Ctor + operator= private machen.

2. Variante:

Makro (Stack)
 #define DEF_SINGLETON( NAME )    \
 public:                        \
    static NAME& instance()      \
    {                            \
       static NAME _instance;    \
       return _instance;         \
    }                            \
 private:                       \
    NAME();               \
    NAME( const NAME& );

 /* Verwendung */
 class N
 {
    DEF_SINGLETON( N )
 public:
    void xyz();
 };
 ...
 N& s = N::instance();
 s.xyz();

Obwohl ich Makros nicht mag, find ich diese Idee irgendwie ziemlich clever. ich brauch nur das eine kleine Makro in die Klassendeklaration schreiben und bin fertig.
Welches Design würdet ihr wählen? Oder ein ganz anderes?

Naja. Mir gefällt das Meyers Singleton einfach am besten. Das ist im wesentlichen eigentlich deine zweite Variante, aber ohne Makros, sondern mit einer Basisklasse. Und ob du jetzt

DEF_SINGLETON( N )

oder

class n : public singleton< n > {}

spielt (von der Schreibarbeit) ja keine Rolle mehr. (oder es halt in jeder Klasse definieren, aber das ist ja eine andere Diskussion).

Naja, aber wenn ich ableite, dann muss ich doch explit noch alle Ctor's und operator= private machen?

Diese 4 Zeilen hast du wohl in null Komma nichts geschrieben. Also nur deswegen auf auf ein Makro setzen, würde ich nicht. Zudem hat man so auch die Möglichkeit zu wählen, ob man sie private oder protected machen möchte. Vielleicht möchte man sie sogar public machen, habe ich auch schon gesehen.

Grüssli

getInstance() { static LoggerTest log; return log;}

geht bei mir also nicht.

Meine Klasse sieht so aus:

#include <cassert>
#include <string>
#include <windows.h>

class LoggerTest {
public:
	static void create(const std::string& filename, int level) {
		if(instance == NULL) {
			instance = new LoggerTest();
			instance->createImpl(filename, level);
		}
	}

	static LoggerTest* getInstance() {
		assert(instance);
		return instance;
	}

	static void destroy() {
		if(instance) {
			OutputDebugStr("close file\n");
			delete instance;
			instance = NULL;
		}
	}

	// Methods
	void message() { OutputDebugStr("message\n"); }

private:
	LoggerTest() { }
	LoggerTest(const LoggerTest& rhs);
	LoggerTest& operator=(const LoggerTest& rhs);

	static LoggerTest* instance;

	void createImpl(const std::string& filename, int level) { 
		OutputDebugStr("open file\n");
	}
};

// In Logger.cpp:
LoggerTest* LoggerTest::instance = NULL;

Die Ideen meiner Klasse: Die Klasse hat Methoden createImpl() und destroy(). createImpl() öffnet die Dateien usw. destroy() schließt die Dateien. Man benutzt meine Klasse in dem man EINMAL create(foo, bar) aufruft und dann nur noch getInstance(). Jetzt habe ich die Klasse mal getestet:

LoggerTest::create("", 2);       // ruft createImpl() auf, öffnet Dateien
LoggerTest* log = LoggerTest::getInstance();

log->message();                 // schreibt nachricht
LoggerTest::getInstance()->message();  // dito

LoggerTest::destroy();          // schließt dateien. delete instance

log->message();                 // dieser aufruft funktoniert! Wieso?
LoggerTest::getInstance()->message();

// Das hier gibt ein assert
Im Grunde steht meine Frage schon im vorletzten Kommentar. Nachdem ich destroy() aufgerufen hab, klappt log-message() dennoch! Das versteh ich nicht. Nach destroy müsste doch log auf gelöschten Speicher zeigen und dann bei log->message() einen Fehler bringen. Wieso gibt das keinen Fehler?

Wieso gibt das keinen Fehler?

Weil es undefiniertes Verhalten ist. Es wäre i.O. wenn die Welt explodiert oder deine Festplatte gelöscht wird. Es ist nicht definiert, was dann passiert, bzw. der Standard sagt eben dazu: undefined behavior.
Dies erlaubt den Kompilern unnötige Prüfungen wegzulassen, wodurch das Programm besser optimiert werden kann. Natürlich liegt dann mehr Verantwortung beim Programmierer.

Grüssli

halte ich nicht für die allerbeste möglichkeit...

ich würde das get_instance() anders implementieren und der programmierer müsste dann halt noch die init-fkt (createImpl) selbst aufrufen - aber ist wohl geschmackssache...

bb

Du rufst eine Funktion auf, die den this-Zeiger nicht braucht. Somit wird da da gar nie auf den 0-Zeiger zugegriffen.

Versteh ich nicht. 1. braucht message() einen this Zeiger und 2. zeigt log auf Müll.

@Dravere: Verstehe. Es ist also im Grunde ein Fehler. Wie könnte ich meinen Code denn ein bißchen umschreiben, dass er funktioniert bzw besser ist?

drakon schrieb:

Du rufst eine Funktion auf, die den this-Zeiger nicht braucht. Somit wird da da gar nie auf den 0-Zeiger zugegriffen.

Versteh ich nicht. 1. braucht message() einen this Zeiger und 2. zeigt log auf Müll.

Das es undefiniert ist habe ich vergessen zu sagen, aber üblicherweise funktioniert das eben, weil kein this Zeiger gebraucht wird. Ich nehme mal nicht an, dass OutputDebugStr eine Member der Klasse ist und daher wird der this Zeiger eben nicht gebraucht..

Schlussentlich ist ja auch der -> - Operator lediglich das hier:

operator -> ( log );

Und wenn du jetzt innerhalb der Funktion log nicht benutzt, dann passiert auch nichts. (kann aber trotzdem einen Fehler geben, da undefiniert).

@Dravere: Verstehe. Es ist also im Grunde ein Fehler. Wie könnte ich meinen Code denn ein bißchen umschreiben, dass er funktioniert bzw besser ist?

Fass den Zeiger nachdem du ihn auf 0 gesetzt hast einfach nicht mehr an..

wolke_ schrieb:

@Dravere: Verstehe. Es ist also im Grunde ein Fehler. Wie könnte ich meinen Code denn ein bißchen umschreiben, dass er funktioniert bzw besser ist?

Fass den Zeiger nachdem du ihn auf 0 gesetzt hast einfach nicht mehr an..

Das ist die übliche Methode und wird auch meistens so gemacht. Allerdings gäbe es auch eine Möglichkeit über SmartPtr etwas zu machen. Du könntest zum Beispiel einen shared_ptr speichern und auch zurückgeben. Wenn du destroy aufrufst, gibst du den shared_ptr im Singleton frei, der Speicher wird aber erst freigegeben, wenn der letzte Benutzer ihn nicht mehr verwendet.
Du kannst aber auch eine eigene SmartPtr-Klasse implementieren, welche immer prüft, ob der Zeiger noch gültig ist und wenn nicht, beim Zugriff darauf eine Exception wirft.
Ein ganz einfaches Beispiel:

class LoggerTestInstance
{
public:
  LoggerTest* operator ->()
  {
    LoggerTest* instance = LoggerTest::getInstance();

    if(!instance)
    {
      throw Fehler();
    }

    return instance;
  }
};

// Verwendung:
LoggerTestInstance loggerTest;
loggerTest->message();

Kann man beliebig erweitern und verbessern

Es gibt viele weitere komplexe Wege, aber am einfachsten ist es, nach destroy nicht mehr anfassen

Grüssli

Dravere schrieb:

Es gibt viele weitere komplexe Wege, aber am einfachsten ist es, nach destroy nicht mehr anfassen

Ja, genau so werde ich es auch machen. Mit shared_ptr usw. find ich schon wieder mit Kanonen auf Spatzen schießen. Am Ende krieg ich sonst noch total "overdesigned" Code wie in boost und komme zu nix mehr Der Benutzer darf den Logger nach destroy() einfach nicht mehr benutzen und fertig.