ich habe eine Singleton Klasse geschrieben. Mein Problem ist, das der Destruktor nicht aufgerufen wird. Habe schon mal gegooglt und habe unter anderem gelesen, dass der Destruktor am Ende des Programmes einmal aufgerufen wird. Dies ist hier ja nicht der Fall.

Spielerdatenbank.h

#ifndef SPIELERDATENBANK_H
#define SPIELERDATENBANK_H
#include <iostream>

namespace Spieler{
    class Datenbank
    {
    public:
        static Datenbank* getInstance(){
            if(Instance == 0){
                Instance = new Datenbank();
            }
            return Instance;
        }

    private:
        static Datenbank* Instance;
        Datenbank(){
            std::cout << "Erschaffen" << std::endl;
        }
        ~Datenbank(){
            std::cout << "Zerstören" << std::endl;
        }
    };
    Datenbank* Datenbank::Instance(0);
}
#endif // SPIELERDATENBANK_H

main.h

int main(int argc, char *argv[]){
    Spieler::Datenbank* t= Spieler::Datenbank::getInstance();
    return 0;
}

Ausgabe:

Erschaffen

Meine Frage: Warum wird der Destruktor nicht aufgerufen? Mache ich etwas falsch oder wird der Destruktor bei einem Singleton am Ende nicht aufgerufen? Mit Ende meinte ich übrigens, wenn das Programm terminiert.

Du schreibst kein delete.

Danke für deine Antwort, aber um ehrlich zu sein, ich kann mir nicht vorstellen wie dieses delete aussehen soll.
Wird am Ende der main Funktion nicht für jedes noch existerende Objekt einmal ein Destruktor aufgerufen?

mfg
Fettpet

Wird am Ende der main Funktion nicht für jedes noch existerende Objekt einmal ein Destruktor aufgerufen?

Nein, nur für Objekte mit automatischer oder statischer Speicherdauer.

Implementiere den Pointer als smart-pointer, dann geht es.

Danke für den Tipp, jetzt macht er genau dass, was er soll. Smart Pointer stehen auch schon seit rund einem Jahr auf meiner ToDo Liste.

Hier ist mal noch die Lösung:

#ifndef SPIELERDATENBANK_H
#define SPIELERDATENBANK_H
#include <iostream>
#include <memory>

namespace Spieler{
    class Datenbank
    {
    public:
        static Datenbank* getInstance(){
            if(Instance.get() == 0){
                Instance = std::auto_ptr<Datenbank> (new Datenbank());
            }
            return Instance.get();
        }
        ~Datenbank(){
            std::cout << "Zerstören";
        }
    private:
        static std::auto_ptr<Datenbank> Instance;
        Datenbank(){
            std::cout << "Erschaffen";
        }

    };
    std::auto_ptr<Spieler::Datenbank> Datenbank::Instance(0);
}
#endif // SPIELERDATENBANK_H

mfg
Fettpet

b) Gib doch anstatt einen Zeiger eine Referenz zurück:

static Datenbank& getInstance()
{
    if(Instance.get() == 0)
    {
        Instance = std::auto_ptr<Datenbank> (new Datenbank());
    }
    return *Instance;
}

c) Wieso eigentlich einen Zeiger mit eigener Speicherverwaltung? Wieso kein richtiges Objekt?

class Datenbank
{
public:
	static Datenbank& getInstance(){
		static Datenbank Instance;
		return Instance;
	}
	~Datenbank(){
		std::cout << "Zerstören";
	}
private:
	Datenbank(){
		std::cout << "Erschaffen";
	}
};

ich habe eine Singleton Klasse geschrieben.

Da liegt dein Problem.

Fettpet schrieb:

ich habe eine Singleton Klasse geschrieben.

Da liegt dein Problem.

Ich wusste das so ein Kommentar kommt.
Singeltons sind und bleiben ein anerkanntes Design Pattern und es gibt garantiert auch Fälle, wo man sie benötigt - bestimmt, denke ich.

Der Nachteil des Singletons ist im Prinzip, dass man sehr schnell diese einzelne Instanz als Globales Gott Objekt benutzt. So wird eine hohe Kopllung der Komponenten erreicht und zusätzliche Abhängigkeiten eingebaut. Und das widerspricht der OOP sowie gutem Programmierstil.

Andererseits bieten sich andere Patterns (wie die 3 Factories) an, um als Singleton genutzt zu werden. Aber auch hier sollte man vorsichtig sein, denn durch eine gute Strukturierung kann trotzdem ein Singleton vermieden werden.

Kurzum: Singleton mal so für 'ne Übung verwenden, oder mal bei nem kleinen Projekt -> ok
Aber wenn's an's Eingemachte geht, Finger weg. Auch wenn die Versuchung groß ist.

Zum TE: Wenn du eine Datenbank damit modellierst, bedeutet das, dass diese Datenbankklasse die Verbindung zur eigentlichen Datenbank darstellt? Sprich, im Konstruktor eröffnest zu eine Verbindung zur Bank und Destruktor schließt du sie? Und das sei der Grund für ein Singleton?!

Weil wenn ja, dann frage dich mal, wieso das so sein sollte? Wieso soll eine Programm annähernd seine gesamte Lebensdauer eine Verbindung zu einer Datei oder Datenbank halten? Und was passiert bei Verbindungsabbrüchen? Oder bei Multithreading?

Zum TE: Wenn du eine Datenbank damit modellierst, bedeutet das, dass diese Datenbankklasse die Verbindung zur eigentlichen Datenbank darstellt? Sprich, im Konstruktor eröffnest zu eine Verbindung zur Bank und Destruktor schließt du sie? Und das sei der Grund für ein Singleton?!

Genau das habe ich mit dem Singleton vor.
Wie ich unschwer rauslesen konnte, scheint dies keine gute Idee zu sein. Was habt ihr für Vorschläge, für ein besseres Design?

mfg
Fettpet

Meist läuft das auf "ich muss nicht ständig Parameter übergeben" aka. "ist bequemer" bzw. "ich muss mir keine Gedanken um Abhängigkeiten machen" hinaus. Und hier liegt das Problem...