Singleton oder "rein statische" Klasse

[Daniel E.]

Original erstellt von HumeSikkins:
Das Problem das ich in diesem konkreten Fall damit habe ist, dass du damit erwartest, dass alle die mit dir kommunizieren wollen dein Genie besitzen müssen.

Das hast Du jetzt mit deinen hellseherischen Kräften herausgefunden, nehme ich an?

Deine 'Erfahrungen mit Extrem-Viel-Wissern wie mir' in allen Ehren, aber Du überschätzt mich gewaltig. Ich will _wirklich_ etwas lernen und trolle nicht (genau darum hatte ich ja geschrieben, dass ich auf dem Gebiet neu bin...). Wenn ich mal etwas mehr Zeit habe als diese Woche, dann werde ich mich mal da reinlesen. Versprochen.

[ Dieser Beitrag wurde am 31.03.2003 um 16:03 Uhr von Daniel E. editiert. ]

[Walli]

Ich habe mir vor zwei Monaten auch mal das "Entwurfsmuster"-Buch von Addison-Wesley gekauft. Manche Design-Patterns finde ich ganz nützlich wenn es Sinn macht. Manches ist einfach zu abgehoben... Singletons sind manchmal ok aber wenn ich sehe wofür manche Leute sie verwenden und dass viele sich für jeden kleinen Mist eine AbstractFactory schreiben dann frage ich mich ob Design-Patterns manchmal nicht einfach ein Rückschritt sind...

[Gerard]

Original erstellt von kartoffelsack:
**Der Vorteil eines Singletons ist doch, dass garantiert ist, dass das Teil korrekt instanziiert ist, wenn es das erste mal benutzt wird. Bei Klassen mit statischen Members ist das genauso garantiert, wie bei globalen Variablen: garnicht. Die Reihenfolge der Instanziierung ist modulübergreifend nicht definiert.
**

außerdem wirds nur instanziert wenn man es braucht

zeigt mir ein besseren weg

- Um das Prog ein wenig lahmer zu machen. (Beim Umbau von globaler Variablen in Meyers-Singleton.)

hmm ich habe mich schon immer gefragt wieso ein compilier nicht zu compilier zeit merkt das die getinstanz() aufgerufen wird und dann die getinstanz umwandelet zu

foo f;

class foo
{
    statuc foo & getinstanz()
    {
        return f;
    }
};

ich sollte mal mit einen der neueren compiliern das testen

[Knuddlbaer]

foo f;

class foo
{
statuc foo & getinstanz()
{
return f;
}
};

Hättest Du dann nicht wieder eine globale Variable die keine Garantie zur Zeit der Instanziierung hat ?!

[Gerard]

Original erstellt von Knuddlbaer:
Hättest Du dann nicht wieder eine globale Variable die keine Garantie zur Zeit der Instanziierung hat ?!

nicht für der compilier bauer, er hat die lizenz zum zaubern

[Knuddlbaer]

Jo stimmt.

Aber wo wäre dann der Vorteil ?

[HumeSikkins]

wenn ich sehe wofür manche Leute sie verwenden und dass viele sich für jeden kleinen Mist eine AbstractFactory schreiben dann frage ich mich ob Design-Patterns manchmal nicht einfach ein Rückschritt sind...

Was meinst du wohl, warum *nahezu jeder* DP-Auskenner auch vor DPs warnt? Auch DPs sind nicht die lang gesuchte "silver-bullet". DPs helfen häufig in verzwickten Situationen (schließlich sind sie genau aus solchen entstanden). Wer aber ohne Not DPs anwendet, holt sich unnötige Komplexität ins Haus. Das resultiert im bekannten "overengineering" und das wiederum führt gerne auch mal zum Scheitern eines Projekts.

[volkard]

Original erstellt von Dimah:
hmm ich habe mich schon immer gefragt wieso ein compilier nicht zu compilier zeit merkt das die getinstanz() aufgerufen wird und dann die getinstanz umwandelet zu...

weil er's nicht kann.
Im Konstruktor vom Singleton SocketProvider wird die winsock.dll geöffnet. Sofern sie da ist, natürlich. Im Handbuch zum Programm steht: Falls die winsock.dll nicht da ist, dann versuchen Sie nicht, Dinge zu verschicken.

Da ist ja der Witz am Meyers-Singleton. Das Objekt wird erst konstruiert, wenn (falls) es gebraucht wird. Dafür zahlt man bei jedem Zugrif die Kosten für ein if.

Falls der Konstruktor nix schlimmes anstellt, darf der Compiler natürlich ein

Bla& getInstance()
{
  static Bla bla;
  return bla;
}

in ein

static Bla bla;//ups, globale variable UND singleton auf einmal.
//jetzt ist der schöne unterschied kaputt.
Bla& getInstance()
{
  return bla;
}

verwandeln.
Andererseits darf das der Programmierer auch gerne selber tun. Er muß sich eh Gedanken machen, wann immer sein Objekt leben soll, sobald er mit Singleton-Dingen beginnt.

[Gerard]

Original erstellt von volkard:
Andererseits darf das der Programmierer auch gerne selber tun. Er muß sich eh Gedanken machen, wann immer sein Objekt leben soll, sobald er mit Singleton-Dingen beginnt.

ich: ich will aber ne lib schreiben, die nicht nur ich benutzen soll
fritz: dann teile die lib auf header auf und include nur das was du brauchst
ich: aber dann habe ich immer noch das problem das mein singelton mehrfach instanzier werden kann
fritz: fang das doch mit ein assert ab
ich: aber ist so ein assert nicht schon aufwändiger als ein singelton? ich meine in der docu erwähnen wieso und wann usw. (und bevor die leute die docu lesen rätseln sie eine halbe stunde wieso es in diesem ctor ein assert gibt), bei ein singelton muss ich nicht viel erklären

vielleicht mache ich mir das leben unötig schwer in den ich alles versuche in eine schöne(IMO) lib zu packen.
ich hoffe das sich irgend wann mein code output mit den anderen messen kann nur das meiner schöner ist, da für trenniere ich, benutze singeltons in programmen die nur ich zu gesicht bekomme (ist der grund auch so ein lacher wie "globale variablen vermeiden"?)

[ Dieser Beitrag wurde am 01.04.2003 um 01:27 Uhr von Dimah editiert. ]

[volkard]

Original erstellt von Dimah:
ich: ich will aber ne lib schreiben, die nicht nur ich benutzen soll
fritz: dann teile die lib auf header auf und include nur das was du brauchst
ich: aber dann habe ich immer noch das problem das mein singelton mehrfach instanzier werden kann
fritz: fang das doch mit ein assert ab
ich: aber ist so ein assert nicht schon aufwändiger als ein singelton? ich meine in der docu erwähnen wieso und wann usw. (und bevor die leute die docu lesen rätseln sie eine halbe stunde wieso es in diesem ctor ein assert gibt), bei ein singelton muss ich nicht viel erklären

versteh ich net. Natürlich ist ein assert ein Laufzeitfehler und daher böse. Ne globale Variable liegt in ner *.cpp und kann auch durch mehrfaches inkludieren der *.h dadurch nicht mehrfach angelegt werden. ob man jetzt den konstruktor dichtmacht, ist bei globale-var-singleton und bei meyers-singleton ne ganz andere frage. ich habs der einfachheit halber gelassen, und getInstance allein angeboten, denn der dichmachcode wäre bei beiden ja gleich.

[dgfd]

Monostate (oder Borg)

Was ist das? Wie wird es implementiert?

[Helium]

Technisch ja, semantisch nein.
Was ist es dann? Eine Abstraktion von einem Tischbein?

hu? Verstehe ich nicht. Technisch gesehen kannst du deine Variablen a, b, c d, ... nennen, semantisch macht es keinen sinn, da der Name keinerlei Semantik besitzt. Technisch gesehen ist ein Objekt eine Ansammlung von Variablen und Methoden, Semantisch repräsentiert das Objekt etwas unabhängig davon, wie es implementiert wurde (egal, ob es eine doppelt verkettete Liste oder ein Tischbei repräsentiert).

Wieso quätscht man Dinge, die man exakt ein mal braucht in eine Klasse und diese Klasse in ein Singleton? Um die Probleme mit mit der Instantierreihenfolge zu umgehen und welche mit der Zerstörung (Zeitpunkt, Ressourcenfreigabe etc) anzufangen?

Du quetscht doch nicht die Klasse in ein Singleton, sondern die Klasse an sich ist ein Singleton.

Und es ist einfach bequemer. Man sagt einfach Sinlgeton, mache das und das, statt sich selbst darum zu kümmern das richtige mit der entsprechenden globalen Variable zu machen. Natürlich ist es Situationsabhängig. Ich sage nicht verwende nurnoch Singletons.

[Daniel E.]

Original erstellt von Helium:
Technisch gesehen kannst du deine Variablen a, b, c d, ... nennen, semantisch macht es keinen sinn, da der Name keinerlei Semantik besitzt.

[Sinn kann es nicht machen.]

Ein Name ist immer bedeutungsleer. Schlimmer noch: Jedes Textdokument ist bedeutungsleer; Bedeutung bekommt es erst durch den Leser. Für C-Dateien ist der Leser oft auch ein Compiler/Interpreter. C-Programme haben also eine spezielle Semantik, aber diese hängt nicht mit Namen zusammen.

Du quetscht doch nicht die Klasse in ein Singleton, sondern die Klasse an sich ist ein Singleton.

Soso. Und Template-Implementierungen von Singletons existieren nicht, nehme ich an.

[ Dieser Beitrag wurde am 02.04.2003 um 17:38 Uhr von Daniel E. editiert. ]

[Helium]

C-Programme haben also eine spezielle Semantik, aber diese hängt nicht mit Namen zusammen.

Sondern?

[Daniel E.]

Die Semantik der Programmiersprache C ist doch recht eindeutig in der Norm festgeschrieben; der Quelltext alleine ist zwar keine vollständige Beschreibung von dem, was das Programm zur Laufzeit tun wird (Spezialfälle, zB 'undefined behaviour' werden durch die Implementierung definiert, die Semantik von Bibliotheksfunktionen steht nicht in meinem Quelltext, usw usf). Nichtsdestoweniger gibt es keinen Unterschied im Ablaufverhalten der folgenden C++-Programme

/* 1 */
#include <cstdlib>

int main(int argc, char** argv)
{
    int celsius;
    if (argc < 2) return -1;
    celsius = std::atoi(argv[1]);
    return 9 * celsius / 5 + 32;
}

/* 2 */
#include <cstdlib>

int main(int a, char** b)
{
    int c;
    if (a < 2) return -1;
    c = atd::atoi(b[1]);
    return 9 * c / 5 + 32;
}

auch wenn sie andere Variablennamen haben. Wenn die Programme jetzt allerdings mit einem Compiler der fiktiven Sprache AsDdSa übersetzt werden könnten sie Dinge machen, die ich nicht beabsichtigt habe; und sie machen dann auch nicht mehr zwingend das Gleiche.

Kann es übrigens gerade sein, dass wir aneinander vorbeischreiben?