Singleton Destuktor wird nicht aufgeruden

Marthog

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

Fettpet

Marthog schrieb:

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

Skym0sh0

a) Wenn Smart Pointer, dann keinen deprecated auto_ptr, sondern in dem Fall unique_ptr. Maximalst noch shared_ptr, aber der passt hier nicht so gut wie unique_ptr.

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

Kellerautomat

Fettpet schrieb:

ich habe eine Singleton Klasse geschrieben.

Da liegt dein Problem.

Nathan

Kellerautomat schrieb:

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.

knivil

Singleton ist und bleibt ein umstrittenes Designpattern.

Skym0sh0

Umstritten hört sich schon besser an als "Problem".

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?

TyRoXx

Singleton ist ein Antipattern, das nur von Leuten benutzt wird, die den Unterschied zwischen Klasse und Instanz noch nicht begriffen haben.

Fettpet

Skym0sh0 schrieb:

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

Nexus

Grundsätzlich kannst du dich immer fragen, welchen Vorteil dir ein Singleton gegenüber dem naheliegenden Ansatz -- normale Klasse, die nur einmal instanziiert wird -- bringt.

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