[C++] Speicherfreigabe bei statischem Singleton

[Chromanoid]

Singletons sind dann sehr nützlich, wenn man Dienste per Dependency Injection flexibel in einem System nutzen möchte. Das klassische Singleton mit statischer Variable für die Instanz im Kontext einer Sprache wie C++ ist da vielleicht nicht ganz so toll. Naja vielleicht ist es auch kein Singleton mehr, wenn es über eine Registry injected wird, aber zumindest im JSR 330 wird es so genannt...

[Brainsmith]

Auf der einen Seite argumentierst du dass für dich nur rohe Performance zählt, auf der anderen Seite hast du bei einer typischen Implementierung des Singleton Pattern (z.B. Meyers Singleton) wie Schrompf schon sagte bei jedem Zugriff auf den Singleton infolge der statischen Variable mit gewissem Overhead zu rechnen (der Compiler muss ja Code einbaun der checked ob die Variable schon initialisiert wurde). Und dabei ist das Ding noch nichtmal annähernd Thread-Safe.

Zugegeben, das wirkt doch schon ein wenig konfus. Ich habe schlichtweg nicht gewusst, dass bei jedem Zugriff Overhead entsteht. Ich hab gedacht, dass nur dann Overhead entsteht, wenn man GetInstance() aufruft. Das wäre dann zum Ladezeitpunkt gewesen, wo Performance einfach mal keine Rolle spielt. Da muss ich was falsch gelesen haben...

In dem Fall hast du natürlich vollkommen recht. Ein Bekannter wollte die Soundengine benutzen und hat mich gebeten einen statischen Singleton zu nutzen. Gefragt, getan. Ich werd das noch mal bequatschen müssen.
Der Weg zur Hölle ist mit guten Vorsätzen geebnet. Bestes Beispiel meinerseits. :D

[Aramis]

aber zumindest im JSR 330 wird es so genannt...

Ich sag's ja echt ungern, aber im Titel ist ein C++-Tag :-)

Die Idee, Singletons durch DI der benoetigten Interfaces de-fakto loszuwerden, ist aber eigentlich eine ziemlich elegante – aber wenn es in der C++–Welt ueblich waere, jeder Funktion ihre kompletten Abhaengigkeiten als Parameter zu geben, haetten wir sowieso eine ganze Menge Probleme weniger.

[dot]

Singletons sind dann sehr nützlich, wenn man Dienste per Dependency Injection flexibel in einem System nutzen möchte.

Was genau meinst du damit? Damit würde man doch die Nachteile beider Patterns kombinieren, oder überseh ich da was!?

Ich hab gedacht, dass nur dann Overhead entsteht, wenn man GetInstance() aufruft.

Natürlich entsteht nur dann Overhead. Aber die übliche Vorgehensweise ist eben genau immer über GetInstance() an die Instanz zu kommen!?

Die Idee, Singletons durch DI der benoetigten Interfaces de-fakto loszuwerden, ist aber eigentlich eine ziemlich elegante [...]

Wenn du mich fragst ist das der einzig vernünftige Weg, Singletons sind imo jedenfalls keine Lösung. Aber ja, leider hat kaum einer den Singleton Pattern wirklich verstanden und darum verwendet ihn jeder überall obwohl er eigentlich wenn überhaupt ein extremes Nischendasein fristen sollte.

[Chromanoid]

Singletons sind dann sehr nützlich, wenn man Dienste per Dependency Injection flexibel in einem System nutzen möchte.

Was genau meinst du damit? Damit würde man doch die Nachteile beider Patterns kombinieren, oder überseh ich da was!?

Welche Nachteile meinst du denn?

Service
ServiceImplA (soll nur einmal pro Programm erzeugt werden -> "Singleton")
ServiceImplB (soll nur einmal pro Programm erzeugt werden -> "Singleton")

Konfigurations-Datei oder Modul-Klasse a'la Guice setzt ServiceImplB für Service

KlasseX benötigt Service und die Instanzen bekommen ServiceImplB injiziert.

[Schrompf]

Woher kommt denn da das "Soll nur einmal pro Programm erzeugt werden"? Das frage ich mich immer bei diesen Geschichten. Wenn Du nach Konfigdatei eine der beiden Klassen auswählen sollst, brauchst Du eine Factory. Die könnte dann auch das "nur einmal erzeugen" implementieren, ohne das man die Klasse selbst damit belasten müsste.

Das Reinreichen dieser Instanz in abhängige Module ist nach meiner Betrachtung dann schon ein anderes Thema - Standard Dependency Injection. Gute Sache, kann man so machen. Hat mit dem Thema "Singleton" aber nix zu tun.

[Chromanoid]

Woher kommt denn da das "Soll nur einmal pro Programm erzeugt werden"? Das frage ich mich immer bei diesen Geschichten. Wenn Du nach Konfigdatei eine der beiden Klassen auswählen sollst, brauchst Du eine Factory. Die könnte dann auch das "nur einmal erzeugen" implementieren, ohne das man die Klasse selbst damit belasten müsste.

Naja wie ich schon eingangs erwähnte, wird in JSR 330 die Annotation, die Klassen als "Soll nur einmal pro Programm erzeugt werden" markiert, @Singleton genannt. Dass es sich dabei vielleicht nicht mehr um ein Singleton handelt, habe ich ja bereits oben angesprochen...

Dort findet man eine Erklärung zum "DI Singleton"
http://code.google.com/p/google-guice/wiki/Scopes

Code: Alles auswählen

@Singleton
public class InMemoryTransactionLog implements TransactionLog {
  /* everything here should be threadsafe! */
}

Und bezüglich der Factory: DI Frameworks sind ja oft auch eine Art Factory, aber eben noch viel mehr...

[dot]

Service
ServiceImplA (soll nur einmal pro Programm erzeugt werden -> "Singleton")
ServiceImplB (soll nur einmal pro Programm erzeugt werden -> "Singleton")

Nur um das vielleicht nochmal klarzustellen: Singleton heißt nicht dass man von etwas nur eine Instanz braucht. Singleton sagt explizit dass es eine wesentliche Eigenschaft dieses Typs ist dass es, was auch immer passieren mag, um keinen Preis der Welt jemals und überhaupt irgendwie bis ans Ende aller Tage mehr als eine Instanz dieser Klasse geben darf. Genau das sicherzustellen ist die Aufgabe des Singleton Pattern (hence the name). Dass es nur eine Instanz mit einem globalen Zugriffspunkt gibt ist lediglich eine Konsequenz des Pattern. Man kann jetzt argumentieren inwiefern das eigentlich überhaupt den Grundfesten der OOP widerspricht, aber lassen wir das mal beseite so gibt es immer noch extrem selten einen Typen auf den das vielleicht zutrifft. In allen Fällen (und damit mein ich alle Fälle wo dies evtl. tatsächlich zutrifft, was schon fast jeden heute existierenden Singleton ausschließt) die ich bisher gesehen hab war man besser beraten keinen Singleton einzusetzen. Ich seh in Singleton daher jedenfalls ein typisches Antipattern.

Wenn du also aus deinem ServiceImplA einen Singleton machst dann sagst du damit nicht: "Ich brauch nur einen ServiceImplA" sondern du sagst "Es kann nie mehr als einen ServiceImplA geben denn das würde dem Konzept eines ServiceImplA widersprechen und das muss in der Schnittstelle dieses Typs so auch von vornherein ausgedrückt sein". Und genau da liegt das Missverständnis das uns 99.9999999% aller Singletons beschert...

Ich hab mir jetzt dieses guice Framework da nicht genau angeschaut aber dieses @Singleton schaut mir von der Semantik her eher nach einer globalen Variable als nach einem Singleton aus denn du könntest die Klasse ja theoretisch immer noch manuell Instanzieren wie du lustig bist, @Singleton sagt nur dem Framework dass es immer die selbe Instanz verwenden soll oder!?

[Chromanoid]

genau. deswegen auch meine zweifel daran ob man das noch singleton nennen kann. der begriff "singleton" jedenfalls wird dank jsr 330 jetzt in vielen di frameworks für java und (dadurch auch in) .net benutzt. hier eine erklärung die eigentlich genau das sagt, was du dazu meinst: http://picocontainer.org/antipatterns/s ... ttern.html dennoch wird auch hier in der doku der begriff "singleton-like" eingesetzt :)

[dot]

Naja, natürlich kann man es "Singleton" nennen (so bezeichnet man ursprünglich ja in der Mathematik einfach eine einelementige Menge), aber mit dem Singleton Pattern (um das es hier geht) hat das soweit ich das sehen kann absolut nichts zu tun.

[Chromanoid]

wenn man ein singleton darauf reduziert, dass immer nur eine instanz pro anwendung davon erzeugt werden darf, und eine annotation in zusammenarbeit mit einem di framework als geeignetes mittel für die sicherstellung dieser anforderung akzeptiert, dann kann man imo von einer modernen form des singletons sprechen. die eher technische Beschreibung für die Sicherstellung im gamma mit einer "Instance operation" über eine "class method"/"static member function" ist imo eher zu vernachlässigen. aber langsam wirds wirklich sehr offtopic :)

[dot]

wenn man ein singleton darauf reduziert, dass immer nur eine instanz pro anwendung davon erzeugt werden darf, und eine annotation in zusammenarbeit mit einem di framework als geeignetes mittel für die sicherstellung dieser anforderung akzeptiert, dann kann man imo von einer modernen form des singletons sprechen.

Ok ja, dann kann man drüber diskutieren, wobei ich das doch immer noch als sehr grenzwertig sehen würd da der Typ sich nichtmehr drum kümmert wann und wo die eine Instanz erzeugt wird, aber egal ;)

[BeRsErKeR]

Ich kann diesen ganzen Hass gegen Singletons nicht nachvollziehen. Ich meine, ist etwas von Grund auf "böse", nur weil es an vielen Stellen unnütz oder der "falsche Weg" ist? Ich kann solche Verteufelungen verstehen, wenn bestimmte Ansätze etwas extrem verschlechtern wie Sicherheit, Lesbarkeit usw, aber ein Singleton ist doch nun wirklich nichts was man derart schlecht reden muss. Da gibt es weitaus schlimmere Dinge. Ich habe irgendwie den Eindruck, dass irgendwann mal jemand anfing Singletons zu verteufeln und nun viele mitmachen.

Ich persönlich nutze sehr viele Singletons in meinem Projekt, wohlwissend, dass es globale Instanzen auch tun würden (wobei ich allerdings sehr wahrscheinlich wirklich ein Problem mit der Initialisierungsreihenfolge bekommen könnte). Sie erfüllen die Anforderungen, die ich habe und da ist mir scheißegal wozu sie mal entworfen wurden. Ich glaube ein bischen Gewohnheit und angeeigneter Stil schwingt immer mit und ich habe lange Zeit einen großen Bogen um globale Variablen gemacht, womöglich aus den gleichen Gründen, warum heute viele Singletons so verteufeln: Irgendwo stand, dass es böse ist. Aus dieser Zeit habe ich wohl immer noch die Gewohnheit an Singletons anstatt globaler Variablen und das ist auch ein Grund warum ich extrem negative oder auch extrem positive Meinungen zu etwas sehr vorsichtig und kritisch beäuge.

Ich sehe nicht ein nun meine Gewohnheiten und Projekte komplett umzukrempeln, nur weil Singletons angeblich der falsche Weg sind. Gäbe es einen wirklich ausschlaggebenden Grund, würde ich nicht zögern, aber ich konnte bis heute noch nie feststellen, dass Singletons einen so negativen Einfluss haben, dass es gerechtfertigt wäre, sie überall zu ersetzen oder nicht mehr zu nutzen. Ich bin natürlich dafür, darauf hinzuweisen, dass es anders besser geht oder bestimmte Schwachstellen aufzuzeigen, aber einige Beiträge hier (besonders von dot) grenzen ja gefühlt schon fast an Hasspredigten.

Das Argument (von Schrompf wenn ich nicht irre) "Zeit zu investieren, in Dinge die keinen Vorteil bringen" kann ich noch am ehesten nachvollziehen bzw. es würde mich am ehesten von allen anderen dazu bringen auf Singletons zu verzichten. Allerdings sind 3 Zeilen Code nicht unbedingt eine Menge, die ich als wirklichen Aufwand betrachte. Wenn ich mich von meinem letzten Floh, der mir in den Kopf gesetzt wurde, nämlich "alles globale in OO ist böse", erholt habe, werde ich die Singletons vielleicht auch nach und nach durch globale Instanzen ersetzen (wenn möglich), aber bis dahin überlege ich mir lieber 3 mal ob ich mich von Dingen distanziere, nur weil sie bei vielen Leuten scheinbar unten durch sind.

Habe die Ehre

[CodingCat]

Ich persönlich nutze sehr viele Singletons in meinem Projekt, wohlwissend, dass es globale Instanzen auch tun würden (wobei ich allerdings sehr wahrscheinlich wirklich ein Problem mit der Initialisierungsreihenfolge bekommen könnte).

Dann sind es doch bereits globale Instanzen. ;-)

Singleton heißt, dass von deiner Klasse nur ein einziges Objekt angelegt werden kann, werden darf. Dass dieses einzige Objekt dadurch üblicherweise nebenbei global verfügbar wird, liegt daran, dass Singletons üblicherweise über globale Instanzen implementiert werden. Ob deine globale Instanz jetzt als static in einer statischen Methode vorliegt oder als freie globale Variable außerhalb deiner Klasse definiert wurde, wirkt sich auf die Initialisierungsreihenfolge aus, spielt aber von der globalen Semantik her keine weitere Rolle.
Auch bei einer globalen Instanz ohne das Singleton-Muster wäre deshalb aufgrund der Initialisierungsreihenfolge die static-Variable in einer freien Funktion der freien globalen Instanzvariable gegebenenfalls vorzuziehen.

Um es kurz zu machen: Es geht hier nicht darum, wo genau deine Instanz definiert ist, sondern es geht um den eigentlichen Aspekt des Singletons, die Konstruktionsbeschränkung. Der Grund, warum Singletons praktisch immer eine schlechte Wahl sind, liegt darin, dass diese Konstruktionsbeschränkung Klassen praktisch immer nur unnötig nutzloser macht. Nehmen wir wieder das Beispiel des Loggings her, zunächst die Singletonvariante:

Code: Alles auswählen

class log_file : public noncopyable
{
   file m_file;

   // Hide C~tor & D~tor
   log_file(const string &filename)
      : m_file(filename, overwrite) { }
   ~log_file() { }
public:
   static log_file& instance()
   {
      static log_file log("log.txt");
      return log;
   }

   void write(...) { ... }
};

Über log_file::instance().write(...) lässt sich ins zentrale Logbuch schreiben. Aber das Singleton macht die Sache nur überflüssig kompliziert. Schlimmer, wenn wir jetzt ein weiteres Logbuch für einen speziellen Teilprozess bräuchten, müssten wir die Klasse duplizieren, damit sie mit dem Singleton-Muster konform bleibt. Das ist das absolute Gegenteil jeglicher Objektorientierung.

Ohne uns Gedanken über Singletons zu machen, haben wir exakt dasselbe Verhalten, nur einfacher, und wiederverwendbar, auf folgende Weise:

Code: Alles auswählen

class log_file : public noncopyable
{
   file m_file;

public:
   log_file(const string &filename)
      : m_file(filename, overwrite) { }
   ~log_file() { }

   void write(...) { ... }
};

log_file& default_log()
{
   static log_file log("log.txt");
   return log;
}

Was ist daran schlechter? Nichts. Was ist daran besser? Über global_log().write(...) lässt sich wesentlich kürzer und aussagekräftiger in das zentrale Logbuch schreiben. Brauchen wir weitere globale Logbücher, können wir einfach weitere freie Funktionen AN BELIEBIGEN STELLEN (auch fernab der log_file-Klasse) hinzufügen. Brauchen wir ein Logbuch nur lokal, können wir lokal mal eben eine log_file-Instanz anlegen, ohne überhaupt zusätzliche Funktionen zu benötigen. Man beachte, dass die Initialisierungsreihenfolge exakt dieselbe wie beim Singleton ist.

Fazit: Wir haben durch weniger Design-Aufwand die Komplexität verringert und die Funktionalität wesentlich verbessert, ohne irgendeinen Nachteil einzugehen.

Ich persönlich nutze sehr viele Singletons in meinem Projekt, [...] sie erfüllen die Anforderungen, die ich habe und da ist mir scheißegal wozu sie mal entworfen wurden.

Klar kannst du auch mit Singletons erfolgreich programmieren, du programmierst dann eben schlichtweg nicht objektorientiert. ;-) Es gibt nur keinen Grund, erhöhte Komplexität einzugehen, um sich kostenlose Funktionalität durch Mehraufwand zu verbauen, ohne dabei irgendetwas zu gewinnen.

Wenn ich mich von meinem letzten Floh, der mir in den Kopf gesetzt wurde, nämlich "alles globale in OO ist böse", erholt habe

Das hat prinzipiell gar nichts mit Objektorientierung zu tun, globale Variablen/Operationen/Objekte/Zustände haben mitunter folgende Nachteile: Unabsehbare Seiteneffekte, undurchsichtige Abhängigkeiten, geringere Flexibilität, geringe Wiederverwendbarkeit.
Insbesondere die ersten beiden Punkte sind eine sehr ernste Sache: Wenn nicht klar ist, welche Variablen/Objekte/Zustände durch eine Operation verändert werden, wird es schwierig bis unmöglich, Annahmen über aktuelle Werte und Zustände zu machen, Invarianten zu erhalten sowie anderweitige effektive Konsistenzerhaltung zu betreiben.
Wenn nicht klar ist, welche Module/Operationen von welchen anderen Modulen/Operationen abhängen, ist es sehr leicht, in zyklische Abhängigkeiten zu verfallen, dies reicht von undefiniertem Verhalten mangels korrekter isolierter Initialisierbarkeit bis hin zu undurchschaubaren Endlosrekursionen bei der globalen Verteilung von Ereignissen.

Beim oben beschriebenen Beispiel des Logbuchs ist das keine große Sache, das Logbuch nutzt selbst keine weiteren globalen Objekte, wodurch keine unabsehbaren Seiteneffekte auftreten können, auch die Abhängigkeiten des Logbuchobjekts sind klar. Sobald globale Operationen/Objekte jedoch beginnen, andere globale Variablen/Operationen/Objekte/Zustände zu nutzen, führst du mit jeder weiteren globalen Abhängigkeit eine weitere Ebene der Undurchsichtigkeit ein.

[dot]

Ich denke, Cat hat es schön auf den Punkt gebracht :)

Das Problem ist nicht der richtige Singleton Pattern an sich, sondern der "Singleton" Pattern, eben jene bunte Verpackung für globale Variablen, für die Singleton meist gehalten wird.
Selbst wenn wir die ganzen Probleme globaler Variablen (allem voran die Verschleierung von Abhängigkeiten), die natürlich nicht verschwinden (die Verpackung ändert ja schließlich nichts am Inhalt), mal ignorieren, birgt die Verwendung des Pattern als "Ersatz" für eine globale Variable nur noch zusätzliche Nachteile in sich, ist dabei aber völlig frei von Vorteilen, was kaum verwunderlich ist. Denn dafür ist der Pattern einfach nicht gedacht, war er nie und wird er nie sein.
Der Zweck des Singleton Pattern ist, sicherzustellen, dass von einem Typ unter keinen Umständen, bis ans Ende der Zeit jemals und überhaupt, mehr als exakt eine Instanz erzeugt wird (hence the name). Der Singleton Pattern dient dazu, genau das und nur das auszudrücken, das zu einer Eigenschaft des Typs selbst zu machen. Steht genau so auch auf der ersten Seite des entsprechenden Abschnittes in dem Buch, wo Singleton das erste Mal beschrieben wurde. Wenn man so will, zählen die drei Sätze dort wohl zu den am meisten missverstandenen Worten der Softwareentwicklung (Zugegeben: Die originale Formulierung ist vielleicht etwas unglücklich gewählt). Die Tatsache dass es eine globale Instanz gibt, ist nur eine Konsequenz, nicht aber der Zweck des Singleton Pattern. (important difference here)
Ob das jetzt gut oder schlecht ist, inwiefern das überhaupt dem Grundgedanken von Objektorientiertheit widerspricht, darüber könnte man nun diskutieren. Ist hier aber irrelevant, denn um dieses Pattern gehts ja garnicht.
Fakt ist, dass Anwendungfälle für einen richtigen Singleton extrem selten sind. Ich hab, in all der Zeit die ich nun auf Mutter Erde wandle, noch praktisch keinen gesehen. Selbst in den Fällen, wo man ernsthaft hätte drüber reden können, einen Singleton zu verwenden, hat sich für mich immer noch eine bessere Lösung gefunden.
Das Problem ist nicht, dass irgendwann mal jemand anfing, Singletons zu verteufeln. Das Problem ist, dass irgendwann mal jemand es für eine gute Idee hielt, seine globalen Variablen als Singletons zu tarnen und dann alle mitgemacht haben. Denn Patterns waren grad voll modern und wenn wir brav für alles einen Pattern benutzen, dann kann es ja eigentlich nurmehr toll sein. Und "Singleton" ist natürlich ein sehr praktisches Pattern, bewahrt es einen doch davor, sich tatsächlich Gedanken über Design machen zu müssen. Ich hab einfach meine paar globalen Instanzen, jeder kennt jeden und kann daher ständig auf alles zugreifen. Angenehmer geht's doch eigentlich gar nicht mehr!? Ohne "Singleton" müssten wir uns doch wirklich überlegen, was wann wie voneinander abhängt, wie Objekte in Beziehung treten, interagieren und ob das alles so eigentlich semantisch sinnvoll ist. Am Ende würden wir sogar viel Zeit damit verschwenden, über unser Design zu reflektieren und es zu refactoren, denn ohne "Singleton" tauchen Abhängigkeiten plötzlich in den Schnittstellen auf und wer will das schon, denn so ein Design wäre am Ende noch flexibel...

Meine Meinung basiert jedenfalls auf meiner Erfahrung und nicht auf Dingen, die ich irgendwo mal gelesen hab. Und meine Erfahrung ist, dass der Verzicht auf Singleton eine gute Guideline ist, die einen praktisch immer in Richtung gutes Design zwingt. Die Wahrscheinlichkeit, dass Singleton tatsächlich eine gute Lösung gewesen wäre, ist jedenfalls in etwa so hoch wie die, dass der Hai, der mich, am Tag da ich von meinem zweiten Lottogewinn erfahre, frisst, von einem Blitz getroffen wird und überlebt.

Btw: Ich hege keinen Hass, schon gar nicht gegen ein Software Pattern. Ich hab nur strong Opinions, was manche Dinge betrifft. Von mir aus darfst du machen, was du willst. Ich kann dir nur wünschen, dass du niemals zu dem Punkt kommst, wo du auf einmal doch gern zwei Instanzen hättest. Denn dann kannst du jede einzelne Metastase deines Singleton suchen und herausoperieren. Wobei: Ist eigentlich eine sehr heilsame Erfahrung, auf zweierlei Art ;)

[BeRsErKeR]

Ihr müsst euch nicht wiederholen. Mir sind die genannten Punkte (Nachteile von Singletons, Nachteile von globalen Variablen) durchaus bekannt und ich habe auch diesen Thread hier komplett gelesen. Ich wollte nun eigentlich auch keine Begründungen, warum irgendwas so ist wie es ist. Mich stört eher die Art wie hier teilweise diskutiert wird. Ich habe nichts dagegen wenn man über bestimmte Ansätze, Patterns, etc diskutiert, das finde ich sogar richtig und wichtig, aber in meinen Augen reicht es, wenn man sachlich diskutiert was Vorteile und Nachteile sind. Man muss nicht immer einen "das ist böse"-Aufkleber drauf kleben.

Ich persönlich nutze sehr viele Singletons in meinem Projekt, [...] sie erfüllen die Anforderungen, die ich habe und da ist mir scheißegal wozu sie mal entworfen wurden.

Klar kannst du auch mit Singletons erfolgreich programmieren, du programmierst dann eben schlichtweg nicht objektorientiert. ;-)

Das ist doch aber nichts Schlimmes. C++ bietet nun mal die Möglichkeit nicht alles objektorientiert zu lösen und in vielen Fällen ist das auch nicht ratsam. Globale Variablen können ja bekanntlich sogar die Kapselung in gewissen Situationen erhöhen und für viele Sachen ist es schlichtweg unnötig objektorientiert zu arbeiten. Der Logger ist ja das beste Beispiel.

Wenn ich mich von meinem letzten Floh, der mir in den Kopf gesetzt wurde, nämlich "alles globale in OO ist böse", erholt habe

Das hat prinzipiell gar nichts mit Objektorientierung zu tun, globale Variablen/Operationen/Objekte/Zustände haben mitunter folgende Nachteile: Unabsehbare Seiteneffekte, undurchsichtige Abhängigkeiten, geringere Flexibilität, geringe Wiederverwendbarkeit.
Insbesondere die ersten beiden Punkte sind eine sehr ernste Sache: Wenn nicht klar ist, welche Variablen/Objekte/Zustände durch eine Operation verändert werden, wird es schwierig bis unmöglich, Annahmen über aktuelle Werte und Zustände zu machen, Invarianten zu erhalten sowie anderweitige effektive Konsistenzerhaltung zu betreiben.
Wenn nicht klar ist, welche Module/Operationen von welchen anderen Modulen/Operationen abhängen, ist es sehr leicht, in zyklische Abhängigkeiten zu verfallen, dies reicht von undefiniertem Verhalten mangels korrekter isolierter Initialisierbarkeit bis hin zu undurchschaubaren Endlosrekursionen bei der globalen Verteilung von Ereignissen.

Das ist mir schon bewusst. Aber gerade weil auf vielen Seiten, in Foren und sogar in Büchern globale Variablen und Funktionen dermaßen niedergemacht wurden, wurde man schon vorsichtig. Ich glaube nicht, dass ich der einzige Mensch bin, der lange Zeit einen Bogen um globalen Kram in C++ gemacht hat. Ich hätte mir da eine sachliche Beleuchtung gewünscht, die z.B. auch herausstellt welche Vorteile globale Variablen haben können und das sie doch ihre Daseinsberechtigung haben. Und genauso wünsche ich mir halt auch eine objektive Betrachtung von Singletons (was außer Frage natürlich auch stellenweise vorhanden war). Das Pattern an sich finde ich nicht sinnlos oder falsch. Und wenn es jemand "schöner" findet eine globale Instanz in einer Klasse zu verpacken finde ich da nichts schlimm dran. Klar sollte derjenige dann schon wissen, dass es letztlich nur eine globale Instanz ist, aber ich weiß nicht ob alles, was nicht dem idealen Weg entspricht, gleich immer falsch sein muss. Es ist ein anderer Ansatz der vielleicht auch mehr Zeit beansprucht, aber als ob es nicht etliche solcher Dinge in der Programmierung gibt. Ich kam bislang super mit meinen Singletons zurecht und fand es sehr bequem sie zu nutzen. Für die Implementierung habe ich mich auch nicht tot gemacht. Ich will hier auch nicht für Singletons werben oder sagen, dass sie ganz toll sind. Aber genauso wenig möchte ich halt, dass es in die andere Richtung geht. Ihr müsst euch eigentlich auch gar nicht in irgendeiner Weise rechtfertigen, ich wollte einfach nur mal einwerfen, dass ich es begrüßen würde, wenn man etwas objektiver an die Sache geht. Und ganz wichtig, ich habe nicht jeden angesprochen der hier gepostet hat. Beim Rauslesen ist mir halt besonders dot aufgefallen. Da schwang mitunter ein recht negativer Ton mit, aber das ist halt auch der Nachteil an Medien wie Foren und Chats. Es fehlen Mimik, Gestik, Intonation usw. Da interpretiert man teilweise mehr rein, als eigentlich da ist.

Von daher. Nichts für ungut. Es war mir ein Bedürfnis das mal los zu werden. ;)

[CodingCat]

Das Pattern an sich finde ich nicht sinnlos oder falsch. Und wenn es jemand "schöner" findet eine globale Instanz in einer Klasse zu verpacken finde ich da nichts schlimm dran. Klar sollte derjenige dann schon wissen, dass es letztlich nur eine globale Instanz ist, aber ich weiß nicht ob alles, was nicht dem idealen Weg entspricht, gleich immer falsch sein muss. Es ist ein anderer Ansatz der vielleicht auch mehr Zeit beansprucht, aber als ob es nicht etliche solcher Dinge in der Programmierung gibt.

Das stimmt mich jetzt wirklich traurig. Ich habe dir mit Abstand die sachlichste, umfassendste und präziseste Antwort geschrieben, die ich seit langem irgendwem geschrieben habe.
Ich habe versucht, zu beleuchten, dass SELBST für das Logging, bei dem ein globaler Ansatz, wie in ebendieser Antwort illustriert, durchaus vertretbar sein kann, ein Singleton in aller Regel keine Daseinsberechtigung hat.

Ich habe ausführlichst versucht, zu zeigen, dass es eben nicht um "schöner finden" geht, sondern dass es handfeste Gründe gibt, die Dinge wenn irgendmöglich ohne Singletons zu lösen. Es ist kein anderer Ansatz, der "vielleicht mehr Zeit beansprucht". Sind wir ehrlich, du hast es selbst zuvor in einem Post gesagt, der zusätzliche Aufwand, aus einer Klasse ein Singleton zu machen, ist ein Witz. Aber Sinn und Zweck eines Singletons ist es, die Konstruktion zu beschränken, NICHT der globale Zugriff. Und sofern es nicht einen driftigen Grund gibt, die Anzahl der instanziierten Objekte zu begrenzen, IST das Singleton OBJEKTIV sinnlos und die falsche Wahl.

Das ist mir schon bewusst. Aber gerade weil auf vielen Seiten, in Foren und sogar in Büchern globale Variablen und Funktionen dermaßen niedergemacht wurden, wurde man schon vorsichtig. Ich glaube nicht, dass ich der einzige Mensch bin, der lange Zeit einen Bogen um globalen Kram in C++ gemacht hat. Ich hätte mir da eine sachliche Beleuchtung gewünscht, die z.B. auch herausstellt welche Vorteile globale Variablen haben können und das sie doch ihre Daseinsberechtigung haben.

Abgesehen von so elementaren, isolierten und naturgemäß zentralen Aufgaben wie Logging IST es nach wie vor ratsam, globale Variablen/Objekte/Zustände zu meiden, auch dafür habe ich dir mehrere sachliche Gründe geliefert.

Ich kam bislang super mit meinen Singletons zurecht und fand es sehr bequem sie zu nutzen.

Du sagst es, sie sind bequem. Das wars dann aber auch. Wie dot sagt, ist auch mir kein einziger Fall bekannt, in dem ein Singleton irgendeine Daseinsberechtigung hätte. Wenn du um der Bequemlichkeit Willen zu Lasten guten Designs Entscheidungen triffst, ist das, solange du der einzige Entwickler und Nutzer dieser Software bist, ganz allein deine Sache. Aber dann suche bitte nicht zwanghaft nach objektiven Begründungen, sondern erkenne, dass es dir alleine um die Bequemlichkeit geht. Und sei dir bewusst, dass diese Entscheidung dich in großen Projekten im Nachhinein sehr viel mehr kosten kann, kosten wird, als du mit deiner Bequemlichkeit je gespart hast.

[dot]

Auch wenn ich bei dem Thema gern etwas sarkastisch werd, so denk ich doch, dass genügend objektive Gründe genannt wurden. Offenbar gefallen sie dir nicht, aber das können wir leider nicht ändern. Ich hätte kein Problem damit, auch objektive Vorteile des "Singleton" Pattern zu diskutieren. Ich kenn nur leider keine (kein Sarkasmus, das mein ich wirklich ernst). Niemand wird dich dran hindern, weiter mir "Singletons" zu arbeiten. Was Bequemlichkeit betrifft, bin ich mal so frei, zu vermuten, dass du es einfach nur nicht besser kennst. Ich finde Singletons jedenfalls alles andere als bequem. Warum ständig irgendwo ein ->GetInstance() tippen und den Code damit zumüllen, wenns auch ohne geht!? Ich kann dir nur empfehlen, es mal ohne zu versuchen ;)

Hier nochmal ein paar hoffentlich doch objektive Probleme des Singleton Pattern zusammengefasst:

• Verschleierung von Abhängigkeiten (big issue!)
• Multithreading
• globaler Zustand, macht automatisches Testing zur Qual

[BeRsErKeR]

Das Pattern an sich finde ich nicht sinnlos oder falsch. Und wenn es jemand "schöner" findet eine globale Instanz in einer Klasse zu verpacken finde ich da nichts schlimm dran. Klar sollte derjenige dann schon wissen, dass es letztlich nur eine globale Instanz ist, aber ich weiß nicht ob alles, was nicht dem idealen Weg entspricht, gleich immer falsch sein muss. Es ist ein anderer Ansatz der vielleicht auch mehr Zeit beansprucht, aber als ob es nicht etliche solcher Dinge in der Programmierung gibt.

Das stimmt mich jetzt wirklich traurig. Ich habe dir mit Abstand die sachlichste, umfassendste und präziseste Antwort geschrieben, die ich seit langem irgendwem geschrieben habe.
Ich habe versucht, zu beleuchten, dass SELBST für das Logging, bei dem ein globaler Ansatz, wie in ebendieser Antwort illustriert, durchaus vertretbar sein kann, ein Singleton in aller Regel keine Daseinsberechtigung hat.

Das habe ich nicht bezweifelt und du musst dich nicht bei jedem meiner Statements angesprochen fühlen. Hier wurde natürlich auch sachlich diskutiert, auch von deiner Seite.

Ich habe ausführlichst versucht, zu zeigen, dass es eben nicht um "schöner finden" geht, sondern dass es handfeste Gründe gibt, die Dinge wenn irgendmöglich ohne Singletons zu lösen. Es ist kein anderer Ansatz, der "vielleicht mehr Zeit beansprucht". Sind wir ehrlich, du hast es selbst zuvor in einem Post gesagt, der zusätzliche Aufwand, aus einer Klasse ein Singleton zu machen, ist ein Witz. Aber Sinn und Zweck eines Singletons ist es, die Konstruktion zu beschränken, NICHT der globale Zugriff. Und sofern es nicht einen driftigen Grund gibt, die Anzahl der instanziierten Objekte zu begrenzen, IST das Singleton OBJEKTIV sinnlos und die falsche Wahl.

Man muss halt differenzieren ob man vom Singleton Pattern spricht oder von einer Singleton-Implementierung in C++ mit statischer Variable. Eine globale Instanz ist ja auch nur einmalig vorhanden, genauso wie die statische Variable eines Singletons. Soll heißen, das Singleton Pattern wurde natürlich dafür entworfen, die Konstruktion zu begrenzen, aber es hat in der Implementierung, die hier auch oft angesprochen wurde ganz einfach die Eigenschaft einer globalen Instanz, die in einer Klasse verpackt wurde. Und auch genau dieser Punkt wurde ja auch im Thread als Kritikpunkt gesehen, nämlich das ein Singleton (in der genannten Implementierungsform) eben nichts weiter ist als eine globale Instanz in einer Klasse. Und da gehe ich einfach nicht mit, dass das von Haus aus etwas schlimmes ist. Es ist wie Krishty anmerkte einfach eine Formsache und wer die Form mit Klasse mag, der soll sie doch benutzen. Von mir aus nennen wir es nicht Singleton, sondern "Globale Instanz in einer Klasse verpackt". Und das nutze ich recht gern. Dazu gab es halt Kritik, die eigentlich nichts mit dem Singleton Pattern zu tun hat, sondern eher mit globalen Instanzen.

Das ist mir schon bewusst. Aber gerade weil auf vielen Seiten, in Foren und sogar in Büchern globale Variablen und Funktionen dermaßen niedergemacht wurden, wurde man schon vorsichtig. Ich glaube nicht, dass ich der einzige Mensch bin, der lange Zeit einen Bogen um globalen Kram in C++ gemacht hat. Ich hätte mir da eine sachliche Beleuchtung gewünscht, die z.B. auch herausstellt welche Vorteile globale Variablen haben können und das sie doch ihre Daseinsberechtigung haben.

Abgesehen von so elementaren, isolierten und naturgemäß zentralen Aufgaben wie Logging IST es nach wie vor ratsam, globale Variablen/Objekte/Zustände zu meiden, auch dafür habe ich dir mehrere sachliche Gründe geliefert.

Ich finde leider den Link gerade nicht, aber da gab es mal einen schönen Artikel in dem gezeigt wird, dass globale Variablen (oder halt in einen namespace gepackt) oft sehr viel besser sind, als das ganze als Member von Klassen anzulegen. In diesem Artikel wurde z.B. für eine Klasse ein zugehöriger namespace ála MyClassVars angelegt, in dem "globale" oder besser "namespace-lokale" Variablen extra außerhalb der Klasse angelegt wurden und das ganze hatte den positiven Effekt, dass die Kapselung höher war, als mit Membervariablen. Ich schau mal ob ich den finde. Soll heißen ich habe schon einiges gesehen, wo Variablen außerhalb von Klassen weitaus effektiver und geeigneter waren. Von daher kann ich das nicht unterschreiben.

Ich kam bislang super mit meinen Singletons zurecht und fand es sehr bequem sie zu nutzen.

Du sagst es, sie sind bequem. Das wars dann aber auch. Wie dot sagt, ist auch mir kein einziger Fall bekannt, in dem ein Singleton irgendeine Daseinsberechtigung hätte. Wenn du um der Bequemlichkeit Willen zu Lasten guten Designs Entscheidungen triffst, ist das, solange du der einzige Entwickler und Nutzer dieser Software bist, ganz allein deine Sache. Aber dann suche bitte nicht zwanghaft nach objektiven Begründungen, sondern erkenne, dass es dir alleine um die Bequemlichkeit geht. Und sei dir bewusst, dass diese Entscheidung dich in großen Projekten im Nachhinein sehr viel mehr kosten kann, kosten wird, als du mit deiner Bequemlichkeit je gespart hast.

Ich weiß nicht so recht ob man hier von schlechtem Design sprechen kann. Ich sehe den Vorteil einer globalen Instanz innerhalb einer Klasse auch darin, dass man die Zugehörigkeit besser erkennt. Ich denke für Teammitglieder ist es auch einfacher, wenn sie nach einer GetInstance-Methode "suchen" müssen, als nach der richtigen globalen Instanz. In dem Fall finde ich eigentlich nur einen namespace, der direkt zur Klasse passt (wie oben erwähnt in der Art von namespace MyClassVars) mit der globalen Instanz besser. Wenn die globale Instanz aber irgendwo in einem übergeordneten namespace rumschwirrt oder schlimmer noch im globalen namespace, dann denke ich eher, dass das für andere schwieriger ist als mit einer globalen Instanz in der Klasse. Auch hier spreche ich eher von der C++ Implementierungsvariante und nicht vom Singleton-Pattern selbst.

Was Bequemlichkeit betrifft, bin ich mal so frei, zu vermuten, dass du es einfach nur nicht besser kennst.

Sagen wir mal "besser kanntest". Als ich anfing Singletons zu nutzen war mir vieles wirklich nicht bewusst. Dann kam die große Welle, in der Singletons verpönt waren. Das Hauptprobleme für die meisten Kritikpunkte sehe ich aber einfach in der Art wie man es in C++ implementieren muss. Das Pattern an sich findest du ja auch nicht von Grund auf falsch. Es wurde ja auch nicht umsonst entworfen. Wenn man für ein Singleton bessere Mittel hätte wie z.B. ein C++ Schlüsselwort wäre es sicher angenehmer und auch in manchen Situationen sinnvoll. Was die meisten doch eher stört, ist dass es sich einfach um eine globale Instanz in einer Klasse handelt. Das hat aber an sich nichts mit dem Pattern zu tun, sondern eher mit C++. Es gab zwar auch einige Statements, die Singletons (das Pattern) per se nicht als gut erachten, aber die Mehrheit der Kritik bezieht sich meiner Meinung nach auf die Implementierung in C++. Ich nutze die Singleton-C++-Implementierung einfach wenn ich eine globale Instanz hübsch in einer Klasse verpacken will, vorallem aus o.g. Grund der Zugehörigkeitserkennung. Ich weiß halt, dass wenn ich die Instanz der Klasse haben will, einfach bei ihr über GetInstance anfragen kann. Es geht auch anders, klar, aber ich mag diese Form mehr als eine globale Instanz im Nirvana der namespaces. Das ist aber nur meine persönliche Einstellung.

Ich finde Singletons jedenfalls alles andere als bequem. Warum ständig irgendwo ein ->GetInstance() tippen und den Code damit zumüllen, wenns auch ohne geht!? Ich kann dir nur empfehlen, es mal ohne zu versuchen ;)

Und wieder reden wir eigentlich nicht über das Singleton-Pattern, sondern die C++ Implementierung. Aber mal davon ab. Ich schreibe eigentlich ganz gern ein wenig mehr Code, wenn ich dadurch die Lesbarkeit erhöhe. Bei einer globalen Variable namens MyGlobalInstance wüsste ich nicht unbedingt, ob es da vielleicht nicht noch andere Instanzen der Klasse gibt und wenn ich sie ungünstig benenne weiß ich vielleicht nicht einmal, was diese Instanz ist oder wofür. Bei einem MyClass::GetInstance() weiß ich, dass ich mir eine Instanz eben dieser Klasse hole und außerhalb kann mir dabei sogar gänzlich egal sein, wie mir intern diese Instanz geliefert wird. Aber auch das ist wieder Geschmackssache. Es soll sogar Leute geben, die Operatoren verabscheuen und anstelle von a = b +c; lieber a.assign(b.add(c)); nutzen. Von daher sollte man persönliche Vorlieben nicht immer auch auf andere projezieren. Aber ich will eigentlich gar keine Diskussion ála "das ist besser als das" vom Stapel brechen; das muss schon jeder für sich entscheiden. Ich mag globale Instanzen in Klassen und auch GetInstance. Jedenfalls mehr als globale Variablen ohne eben genanntes.

Hier nochmal ein paar hoffentlich doch objektive Probleme des Singleton Pattern zusammengefasst:

• Verschleierung von Abhängigkeiten (big issue!)
• Multithreading
• globaler Zustand, macht automatisches Testing zur Qual

Betrifft meiner Meinung nach auch eher die C++ Implementierung und nicht das Pattern an sich.

[CodingCat]

Es ist eigentlich alles gesagt. Es wäre nett, wenn du mal versuchen würdest, unsere Antworten zu verstehen, statt dich endlos in schwammigen Konterposts zu wiederholen. Dann würde dir auffallen, dass wir uns so oft wiederholen müssen, um deine vermischten Antworten immer wieder mühsam Punkt für Punkt zu korrigieren. WIR reden hier sehr wohl vom Singleton-MUSTER, und zwar solange, bis wir das Gefühl haben, dass du verstanden hast, worum es eigentlich geht.

Man muss halt differenzieren ob man vom Singleton Pattern spricht oder von einer Singleton-Implementierung in C++ mit statischer Variable.

Nein, muss man nicht. Singleton heißt: NUR EINE INSTANZ. Globale Instanz heißt: GLOBALE ODER STATISCHE VARIABLE. Wenn du Singleton schreibst, heißt das, wir reden von Konstruktionsbeschränkung.

Soll heißen, das Singleton Pattern wurde natürlich dafür entworfen, die Konstruktion zu begrenzen, aber es hat in der Implementierung, die hier auch oft angesprochen wurde ganz einfach die Eigenschaft einer globalen Instanz, die in einer Klasse verpackt wurde. Und auch genau dieser Punkt wurde ja auch im Thread als Kritikpunkt gesehen, nämlich das ein Singleton (in der genannten Implementierungsform) eben nichts weiter ist als eine globale Instanz in einer Klasse. Und da gehe ich einfach nicht mit, dass das von Haus aus etwas schlimmes ist.

Es IST von Haus aus bis auf ganz ganz wenige Ausnahmen etwas schlimmes, Abhängigkeiten, blabla ...

Betrifft meiner Meinung nach auch eher die C++ Implementierung und nicht das Pattern an sich.

Nein, das hat mit C++ absolut nichts zu tun, die Folgen von globalen Objekten/Variablen/Zuständen sind in allen Sprachen dieselben.

Bei einer globalen Variable namens MyGlobalInstance wüsste ich nicht unbedingt, ob es da vielleicht nicht noch andere Instanzen der Klasse gibt und wenn ich sie ungünstig benenne weiß ich vielleicht nicht einmal, was diese Instanz ist oder wofür. Bei einem MyClass::GetInstance() weiß ich, dass ich mir eine Instanz eben dieser Klasse hole [...]

Genau DAS ist die Idee bei der Trennung von Klassen und Objekten: Dass du nicht weißt, wieviele Objekte es gibt, dass du es nicht wissen MUSST, wieviele Objekte es gibt, sondern dass du genau dasjenige Objekt nutzt, welches du gerade benötigst, und die anderen unabhängig davon koexistieren können, ohne in irgendeiner Weise beeinflusst zu werden. Und genau DAS ist das Problem von Signletons und NICHT von globalen Instanzen oder Implementierungen, dass sie in Klassen getarnt jeglicher Objektorientierung widersprechen.

Ich schreibe eigentlich ganz gern ein wenig mehr Code, wenn ich dadurch die Lesbarkeit erhöhe.

Du erhöhst die Lesbarkeit kein bisschen, GetInstance enhält absolut Null Information. WENN du deine GANZ WENIGEN globalen Instanzen UNBEDINGT in die Klasse packen willst (wofür es absolut keinen rationalen Grund gibt), wäre es das mindeste, die Konstruktion weiterer Instanzen trotzdem nicht zu verbieten, und die statischen Methoden sinnvoll zu benennen, beispielsweise Log::DefaultLog() etc. Dennoch solltest du freie Funktionen unbedingt mal probieren, eben aus genanntem Grund der einheitlichen Erweiterbarkeit, außerhalb der Klasse lassen sich gleichförmig beliebig viele weitere Instanzen anfügen, zudem erhälst du damit genannte Unabhängigkeit von Klassen und Objekten.

Das Pattern an sich findest du ja auch nicht von Grund auf falsch. Es wurde ja auch nicht umsonst entworfen. Wenn man für ein Singleton bessere Mittel hätte wie z.B. ein C++ Schlüsselwort wäre es sicher angenehmer und auch in manchen Situationen sinnvoll. Was die meisten doch eher stört, ist dass es sich einfach um eine globale Instanz in einer Klasse handelt.

Such doch bitte Mal nach einem einzigen Fall, in dem ein Singleton sinnvoll wäre. Du wirst sehen, praktisch alles lässt sich mit weniger oder gleichem Aufwand eleganter und funktioneller als normale konstruktionsunbeschränkte Klasse implementieren. Und nein, es stört nicht nur, dass es sich um eine globale Instanz handelt: es stört SOWOHL, dass es sich um eine globale Instanz handelt, ALS AUCH, dass weitere Instanzen verboten werden. Das Singleton bringt ZWEI BEDEUTENDE Nachteile in deine Software, und wenn es nicht einen absolut driftigen Grund dafür gibt, dass NUR GENAU EINE Instanz existieren DARF, ist es einfach nur falsch, diese beiden Nachteile einzugehen. Insofern wäre ein singleton-Schlüsselwort ein hinreichender Grund, eine Sprache grundsätzlich nicht einzusetzen.

In diesem Artikel wurde z.B. für eine Klasse ein zugehöriger namespace ála MyClassVars angelegt, in dem "globale" oder besser "namespace-lokale" Variablen extra außerhalb der Klasse angelegt wurden und das ganze hatte den positiven Effekt, dass die Kapselung höher war, als mit Membervariablen.

Sicher kannst du damit höhere Kapselung erreichen, aber das ist die letzte Art der Kapselung, die du willst. Dazu brauchst du allerhöchstens einen anonymen Namespace, und das was du erhälst, ist ein absolut starres Subsystem, von dem es wie beim Singleton nur exakt eine Instanz gibt, in dem du wie beim Singleton alle Probleme bzgl. globaler Abhängigkeiten, Multithreading, Testing etc. mitnimmst. Wenn dir Kapselung ein sehr sehr großes Anliegen wäre, wäre die richtige Lösung, einfach Zeiger und Referenzen auf vorwärts-deklarierte und übersetzungseinheitslokal definierte Strukturen an freie Funktionen rumzureichen.

[dot]

Cave Johnson, We're done here :)

[BeRsErKeR]

Es ist eigentlich alles gesagt. Es wäre nett, wenn du mal versuchen würdest, unsere Antworten zu verstehen, statt dich endlos in schwammigen Konterposts zu wiederholen. Dann würde dir auffallen, dass wir uns so oft wiederholen müssen, um deine vermischten Antworten immer wieder mühsam Punkt für Punkt zu korrigieren. WIR reden hier sehr wohl vom Singleton-MUSTER, und zwar solange, bis wir das Gefühl haben, dass du verstanden hast, worum es eigentlich geht.

Da ist wohl jemand mit dem falschen Fuß aufgestanden. :D

Man muss halt differenzieren ob man vom Singleton Pattern spricht oder von einer Singleton-Implementierung in C++ mit statischer Variable.

Nein, muss man nicht. Singleton heißt: NUR EINE INSTANZ. Globale Instanz heißt: GLOBALE ODER STATISCHE VARIABLE. Wenn du Singleton schreibst, heißt das, wir reden von Konstruktionsbeschränkung.

Du kannst ein Singleton auch implementieren ohne eine statische Instanz der Klasse anzulegen. Daher finde ich schon, dass man zwischen dem Pattern und der Implementierungsart unterscheiden muss, weil die Implementierung halt auf verschiedenem Wege erfolgen kann, z.B. wie gesagt ohne globale Instanz.

Betrifft meiner Meinung nach auch eher die C++ Implementierung und nicht das Pattern an sich.

Nein, das hat mit C++ absolut nichts zu tun, die Folgen von globalen Objekten/Variablen/Zuständen sind in allen Sprachen dieselben.

Wie gesagt kann man ein Singleton auf verschiedene Weisen implementieren und globale Objekte/Variablen sind dafür nicht zwangsweise nötig. Du scheinst aber davon auszugehen, dass Singleton immer verknüpft ist mit globaler Instanz. Einzigartig heißt aber nicht unbedingt auch global.

Ich schreibe eigentlich ganz gern ein wenig mehr Code, wenn ich dadurch die Lesbarkeit erhöhe.

Du erhöhst die Lesbarkeit kein bisschen, GetInstance enhält absolut Null Information. WENN du deine GANZ WENIGEN globalen Instanzen UNBEDINGT in die Klasse packen willst (wofür es absolut keinen rationalen Grund gibt), wäre es das mindeste, die Konstruktion weiterer Instanzen trotzdem nicht zu verbieten, und die statischen Methoden sinnvoll zu benennen, beispielsweise Log::DefaultLog() etc. Dennoch solltest du freie Funktionen unbedingt mal probieren, eben aus genanntem Grund der einheitlichen Erweiterbarkeit, außerhalb der Klasse lassen sich gleichförmig beliebig viele weitere Instanzen anfügen, zudem erhälst du damit genannte Unabhängigkeit von Klassen und Objekten.

Klar werde ich mir auch die hier genannten Ansätze angucken und vielleicht auch nutzen. Wie gesagt gibt es für mich aber einen rationalen Grund globale Instanzen in Klassen zu packen. Weil ich dann sofort erkenne, dass sie eine logische Zuordnung/Verbindung zu der Klasse hat. Das finde ich beispielsweise bei Konstanten sehr nützlich, die nur in der Klasse verwendet werden und einen Bezug zu ihr haben. Klar kann ich die Konstante auch außerhalb der Klasse anlegen, aber warum sollte irgendjemand anderes als diese eine Klasse überhaupt die Möglichkeit haben an diese Instanz heranzukommen? Ok das ist nun eher ein Beispiel mit privaten statischen Instanzen, aber es ist halt ein Beispiel.

Das Pattern an sich findest du ja auch nicht von Grund auf falsch. Es wurde ja auch nicht umsonst entworfen. Wenn man für ein Singleton bessere Mittel hätte wie z.B. ein C++ Schlüsselwort wäre es sicher angenehmer und auch in manchen Situationen sinnvoll. Was die meisten doch eher stört, ist dass es sich einfach um eine globale Instanz in einer Klasse handelt.

Such doch bitte Mal nach einem einzigen Fall, in dem ein Singleton sinnvoll wäre. Du wirst sehen, praktisch alles lässt sich mit weniger oder gleichem Aufwand eleganter und funktioneller als normale konstruktionsunbeschränkte Klasse implementieren. Und nein, es stört nicht nur, dass es sich um eine globale Instanz handelt: es stört SOWOHL, dass es sich um eine globale Instanz handelt, ALS AUCH, dass weitere Instanzen verboten werden. Das Singleton bringt ZWEI BEDEUTENDE Nachteile in deine Software, und wenn es nicht einen absolut driftigen Grund dafür gibt, dass NUR GENAU EINE Instanz existieren DARF, ist es einfach nur falsch, diese beiden Nachteile einzugehen. Insofern wäre ein singleton-Schlüsselwort ein hinreichender Grund, eine Sprache grundsätzlich nicht einzusetzen.

Das ist nun vielleicht weit hergeholt, aber nehmen wir mal an, es existiert ein Thread-Objekt, welches auch wirklich einen realen Thread repräsentiert in irgendeiner Weise. Das System unterstützt kein Multi-Threading und crasht wenn ein zweiter Thread gestartet wird oder schlimmer noch, überschreibt den alten. Wenn ich da nicht sicherstelle, dass nur ein Thread-Objekt gleichzeitig instanziiert wird, kann das recht übel enden. Wenn die ganze Initialisierung irgendwo drunter und schon vorm Inhalt des Konstruktors der Thread-Klasse passiert, kann ich da auch nicht mehr viel abfangen. Kurz gesagt, wenn ein System nicht unterstützt dass es gewisse Konstrukte mehrfach gibt, dann sollte es auch im Code sichergestellt werden, dass auf keinen Fall eine zweite Instanz existiert. Das wird in der Realität wohl kaum vorkommen, aber es wäre halt ein Anwendungsbeispiel.

[CodingCat]

Da ist wohl jemand mit dem falschen Fuß aufgestanden.

Nein, ich finde es schlicht unverschämt, wenn sorgfältig und umfassend formulierte Antworten mit hingeklatschten wirren Pseudoargumenten "widerlegt" werden sollen.

Wie gesagt kann man ein Singleton auf verschiedene Weisen implementieren und globale Objekte/Variablen sind dafür nicht zwangsweise nötig. Du scheinst aber davon auszugehen, dass Singleton immer verknüpft ist mit globaler Instanz. Einzigartig heißt aber nicht unbedingt auch global.

DU hast uns die ganze Zeit erzählt, dass es dir nur um die globale Instanz geht, NICHT ICH.
DU wirfst hier permanent Singletons und globale Instanzen durcheinander, und wenn wir das ganze mühsam auseinanderklamüsern, wirfst du UNS vor, die beiden zu vermischen?!

Ich nutze die Singleton-C++-Implementierung einfach wenn ich eine globale Instanz hübsch in einer Klasse verpacken will.

Singleton heißt: NUR EINE INSTANZ. Globale Instanz heißt: GLOBALE ODER STATISCHE VARIABLE. Wenn du Singleton schreibst, heißt das, wir reden von Konstruktionsbeschränkung.

Da, schau, du musst nur lesen. ;)

Das wird in der Realität wohl kaum vorkommen, aber es wäre halt ein Anwendungsbeispiel.

Siehst du? Na endlich. :)

[BeRsErKeR]

Da ist wohl jemand mit dem falschen Fuß aufgestanden.

Nein, ich finde es schlicht unverschämt, wenn sorgfältig und umfassend formulierte Antworten mit hingeklatschten wirren Pseudoargumenten "widerlegt" werden sollen.

Meine "Kritik" bezog sich weder auf die letzten Beiträge noch auf die sachliche Diskussion. Sie bezog sich auch nie auf dich. Das habe ich ja mehrfach versucht dir klar zu machen. Und ich habe auch nie behauptet, dass alle eure Argumente falsch oder unsachlich sind. Es gab halt einige Beiträge (vorallem auf den ersten Seiten), die ich zu extrem negativ fand. Es geht mir nicht darum wer Recht hat, sondern einfach, dass ich mir bei manchen Beiträgen (das muss keiner von dir sein) mehr Objektivität wünschen würde. Ich wollte eigentlich auch nicht eine neuerliche Diskussion anfangen. Leider ist genau das passiert.

Wie gesagt kann man ein Singleton auf verschiedene Weisen implementieren und globale Objekte/Variablen sind dafür nicht zwangsweise nötig. Du scheinst aber davon auszugehen, dass Singleton immer verknüpft ist mit globaler Instanz. Einzigartig heißt aber nicht unbedingt auch global.

DU hast uns die ganze Zeit erzählt, dass es dir nur um die globale Instanz geht, NICHT ICH.
DU wirfst hier permanent Singletons und globale Instanzen durcheinander, und wenn wir das ganze mühsam auseinanderklamüsern, wirfst du UNS vor, die beiden zu vermischen?!

Ich habe extra betont, dass ich nicht vom Pattern sprach, sondern von der Implementierung mit statischer Variable. Ich habe sogar angemerkt, dass mir egal ist wozu ein Singleton entworfen wurde, wenn diese Implementierung (auch wenn das nichts mit Singleton zu tun hat, aber diese eine Implementierung hat einfach die Form) für mich angenehm ist. Wir müssen uns doch gar nicht darum streiten, ob ein Singleton supertoll ist oder nicht. Darum geht es mir hier gar nicht.

Ich nutze die Singleton-C++-Implementierung einfach wenn ich eine globale Instanz hübsch in einer Klasse verpacken will.

Singleton heißt: NUR EINE INSTANZ. Globale Instanz heißt: GLOBALE ODER STATISCHE VARIABLE. Wenn du Singleton schreibst, heißt das, wir reden von Konstruktionsbeschränkung.

Da, schau, du musst nur lesen. ;)

Das wird in der Realität wohl kaum vorkommen, aber es wäre halt ein Anwendungsbeispiel.

Siehst du? Na endlich. :)

Nur weil ich kein konkretes Beispiel kenne und du auch nicht, heißt das noch lange nichts. Aber egal. Diese Diskussion geht schon viel zu lange und führt nirgendwo hin. Ich hab das Gefühl dass wir einfach aneinander vorbei geredet haben, von daher sollten wir hier vielleicht einfach einen Cut machen. Das Wesentliche um das es in diesem Thread eigentlich mal ging, wurde ja schon zu Genüge gesagt.


Von daher. Lassen wir das.

[CodingCat]

Meine "Kritik" bezog sich weder auf die letzten Beiträge noch auf die sachliche Diskussion. Sie bezog sich auch nie auf dich. Das habe ich ja mehrfach versucht dir klar zu machen. Und ich habe auch nie behauptet, dass alle eure Argumente falsch oder unsachlich sind.

Meine Kritik bezog sich aber sehr wohl auf dich. Wenn du nur die Diskussionsweise kritisieren wolltest, hättest du dich darauf eben auch beschränken müssen. Solange du zusätzlich auf Sachebene versuchst, mit Bauchgefühl dagegen zu argumentieren, und dabei themenrelevante Dinge durcheinander bringst, müssen wir irgendwie korrigierend eingreifen. Für dich mag das egal sein, für andere Leser ist es das nicht.

Diese Diskussion geht schon viel zu lange und führt nirgendwo hin.

Oh doch, ich habe den Eindruck, dass wir hier sehr weit gekommen sind.

[BeRsErKeR]

Sorry dass ich das nochmal auskrame, aber wollte keinen neuen Thread aufmachen.

Ich hätte da mal eine Frage zur Lebenszeit von statischen Membervariablen, rein aus Interesse.

Leben statische Member länger als die globale Klasseninstanzen, die diese enthalten? Also gibt es da eine klare Festlegung?

Beispiel:

Code: Alles auswählen

class foo
{
public:
    ~foo() { printf("%d\n", bar);

private:
    static int bar;
};

foo f; // von mir aus auch static foo f;

Ist in diesem Beispiel gewährleistet, dass bar noch existiert, wenn f zerstört wird?

Ein int ist vielleicht kein gutes Beispiel. bar könnte auch eine Instanz einer anderen Klasse sein, etc.

[dot]

Statische Member haben static storage duration, leben also vom Programmstart bis zum Programmende. Trotzdem sollte man mit sowas sehr vorsichtig sein. Meiner Erfahrung nach braucht man statische Member eigentlich praktisch nie.

[BeRsErKeR]

Das was du sagst ist mir klar, darum sagte ich ja, ich frage aus Interesse. Beantwortet wurde meine Frage nun nicht direkt. Die Klasseninstanz lebt ja auch bis zum "Programmende", aber ist dann die statische Membervariable noch existent?

[CodingCat]

Alle Instanzen werden grunsätzlich in umgekehrter Konstruktionsabschlussreihenfolge zerstört.

Non-local variables with thread storage duration are initialized as a consequence of thread execution.
[...]
Definitions of explicitly specialized class template static data members have ordered initialization. Other class template static data members (i.e., implicitly or explicitly instantiated specializations) have unordered initialization. Other non-local variables with static storage duration have ordered initialization.
[...]
Variables with ordered initialization defined within a single translation unit shall be initialized in the order of their definitions in the translation unit.

Die Konstruktionsreihenfolge INNERHALB EINER ÜBERSETZUNGSEINHEIT entspricht also der Definitionsreihenfolge. Über mehrere Übersetzungseinheiten hinweg ist die Reihenfolge hingegen undefiniert.

In deinem Beispiel lässt sich keine Aussage machen, weil dein static Member bar dort nur deklariert, jedoch nirgends definiert wurde.

[BeRsErKeR]

Sprich es wäre sinnvoll die statischen Member sofort nach der Klasse zu initialisieren? Danke erstmal für die Antwort.