globale variable oder nicht?

[Kellerautomat]

Singleton_1 schrieb:

Wie wäre es mit Singletons?

Um welches Problem zu loesen?

[Cyres]

Singleton_1 schrieb:

Wie wäre es mit Singletons?

Singletones werden überbewertet.

Flutscherino schrieb:

jo eigentlich is es ganz simple, ich rufe von A -> B auf und definiere XY, dann von A -> C und in C ruf ich dann D auf wobei ich in D eben die XY brauche..

void A() {XY xy = B(); C(xy);}
XY B() {//erstelle XY und gebe XY zurück}
void C(const XY& xy) {D(xy);}
void D(const XY& xy) {//...}

Hab ich das so richtig verstanden?

[besserwisser]

Funktion wird im deutschen mit "k" geschrieben. Variable ist ein Substantiv und wird groß geschrieben. Und "tu mal nicht das Projekt initialisieren", sondern "initialisiere das Programm". Und der Start ist auch ein Substantiv, wie auch die Zahl. Also statt "ich tu jetzt das Projekt einmal initialisieren beim start" heißt es richtig "Ich initialisiere das Programm jetzt ein mal beim Start".

[asc]

Grundsätzlich sind globale Variablen nicht gut, aber Singletons sollte man ebenso mit vorsicht geniesen (Ich würde sie zwar nicht gänzlich verteufeln, aber allzu weit von globalen Variablen ist das Singleton nun auch nicht entfernt).

Die Verwendung von Parametern oder Klassenmembern ist in der Regel die bessere Wahl.

[dot]

Singleton und globale Variablen sind zwei völlig orthogonale Konzepte. Das einzige was Singletons und globale Variablen gemeinsam haben ist, dass man praktisch immer, wenn man denkt, dass ein Singleton oder eine globale Variable angebracht wäre, falsch liegt; ganz besonders bei Singleton und ziemlich sicher auch in diesem Fall...

[Erkenner der Hobby Lehrer]

@besserwisser
Kann man bei dir Nachhilfe Unterricht im Fach Deutsch buchen?
(Könntest du eventuell meinen Satz oben etwas verbessern?)

[Swordfish]

Kellerautomat schrieb:

Singleton_1 schrieb:

Wie wäre es mit Singletons?

Um welches Problem zu loesen?

Zu wenige design patterns im Programm.

[Nexus]

Flutscherino schrieb:

ich höre immerwieder das Globale Variablen schlecht sind, aber warum?

Begründung

dot schrieb:

Singleton und globale Variablen sind zwei völlig orthogonale Konzepte.

Zeig mir ein nicht-globales Singleton.

[dot]

Nexus schrieb:

dot schrieb:

Singleton und globale Variablen sind zwei völlig orthogonale Konzepte.

Zeig mir ein nicht-globales Singleton.

Zeig mir einen nicht strahlenden Kernreaktor. Die Tatsache, dass ein Singleton in der Regel einen globalen Zugriffspunkt bietet, ist lediglich eine Konsequenz, aber nicht der eigentliche Sinn des Pattern, eine unerwünschte Nebenwirkung, könnte man sagen...

[Nexus]

Das stimmt, aber man kommt eben nicht ohne globale/statische Variablen aus, wenn man das klassische Singleton-Pattern implementiert. Andererseits sieht man oft den Fehler, dass jede Klasse, die nur einmal instanziiert wird, gleich zu einem Singleton gemacht wird. Bei Spielen z.B. die furchtbaren globalen Manager für alles :p

[dot]

Nexus schrieb:

Andererseits sieht man oft den Fehler, dass jede Klasse, die nur einmal instanziiert wird, gleich zu einem Singleton gemacht wird.

Genau das ist der Punkt. Eine globale Variable ist eine Instanz eines Typs. Ein Singleton ist ein Typ, der nur einmal instanziert werden kann.
Auch wenn die übliche Implementierung eines Singleton in C++ einen globalen Zugriffspunkt auf diese eine Instanz impliziert, sind das imo immer noch zwei völlig unabhängige Konzepte, wie z.B. "Flugzeug" und "Urlaub" auch...

[daddy_felix]

dot schrieb:

[...] sind das imo immer noch zwei völlig unabhängige Konzepte, wie z.B. "Flugzeug" und "Urlaub" auch...

ob Jürgen Wolf das auch so sieht?

class Flugzeug : public Urlaub
{};

*duckwundweg*

[asc]

dot schrieb:

Singleton und globale Variablen sind zwei völlig orthogonale Konzepte.

Sie mögen unterschiedliche Konzepte sein, doch wurden letztere in den Projekten in denen ich gearbeitet habe nicht selten für das gleiche verwendet. z.B. für das halten einer globalen Konfiguration (mit schönen Fehlereffekten wegen Abhängigkeiten und Linkreihenfolgen die sich geändert hatten)...

dot schrieb:

Das einzige was Singletons und globale Variablen gemeinsam haben ist, dass man praktisch immer, wenn man denkt, dass ein Singleton oder eine globale Variable angebracht wäre, falsch liegt; ganz besonders bei Singleton und ziemlich sicher auch in diesem Fall...

Bei globalen Variablen ist dies in der Regel ebenso falsch (Ich würde im Zweifel sogar ein Singleton vorziehen, da die Initialisierung hier "definierter" abläuft).

Ich verwende auch in Projekten vereinzelt Singletons, weil mir für den Anwendungsfall keine bessere Lösung eingefallen ist (Rechte zum Angemeldeten Benutzer, die in der Regel nur einmalig initialisiert werden, und an sehr vielen Programmstellen abgefragt werden; Ebenso nutzen wir das Application-Objekt von der VCL [Merkt sich u.a. die Aufrufparameter], das man sowohl als globale Variable als auch als Singleton umsetzen kann - vermutlich ist es ersteres, habe es aber nicht nachgeprüft).

[Braunstein]

Wir verwenden gerade für solche globalen Konfigurationen auch Singletons.
@asc Aus deiner Bemerkung dazu schließe ich, dass ihr dafür jetzt keine Singletons mehr verendet. Wie macht man es dann? Mir ist hier dazu nichts besseres als Singleton (oder eben globale Variable) eingefallen.

[Ethon]

Ich würde globale Variablen einfach so verpacken und gut:

std::vector<Item>& globalItems()
{
   static std::vector<Item> items;
   return items;
}

Solange man den globalen ZUgriff nur möglichst lokal verwendet und abkapselt, wo ist das Problem.

[dot]

asc schrieb:

dot schrieb:

Singleton und globale Variablen sind zwei völlig orthogonale Konzepte.

Sie mögen unterschiedliche Konzepte sein, doch wurden letztere in den Projekten in denen ich gearbeitet habe nicht selten für das gleiche verwendet.

Naja, das machts aber eben noch lange nicht gut oder richtig...

asc schrieb:

Bei globalen Variablen ist dies in der Regel ebenso falsch (Ich würde im Zweifel sogar ein Singleton vorziehen, da die Initialisierung hier "definierter" abläuft).

Wenn ich einfach nur wohldefinierte Initialisierungsreihenfolge brauch, dann kann ich auch einfach eine normale Funktion machen, die das entsprechende Objekt in Form einer statischen Variable instanziert und eine Referenz drauf zurückgibt, ich seh nicht, wieso genau da automatisch das Singleton Pattern benötigt würde!?

asc schrieb:

Ebenso nutzen wir das Application-Objekt von der VCL [Merkt sich u.a. die Aufrufparameter], das man sowohl als globale Variable als auch als Singleton umsetzen kann - vermutlich ist es ersteres, habe es aber nicht nachgeprüft).

So ein Application Objekt wäre imo evtl. sogar einer der seltenen Fälle, wo man tatsächlich drüber diskutieren könnte, ob das Singleton Pattern dabei angebracht wäre, da man es hier ausnahmsweise wirklich mit etwas zu tun hat, das zu seiner wesentlichen Eigenschaft hat, dass es nur einmal existiert.

asc schrieb:

z.B. für das halten einer globalen Konfiguration (mit schönen Fehlereffekten wegen Abhängigkeiten und Linkreihenfolgen die sich geändert hatten)...

Braunstein schrieb:

Wir verwenden gerade für solche globalen Konfigurationen auch Singletons.

Und mit genau welcher Begründung? Wieso genau muss um jeden Preis sichergestellt werden, dass die entsprechenden Typen hier und jetzt, für alle Zeit und überhaupt niemals je mehr als genau einmal instanziert werden? So lange du dafür kein Argument hast, hast du keinen Grund um einen Typen zu einem Singleton zu machen. Zugegeben, eine applikationsweite Konfiguration ist unter Umständen ein Grenzfall, wo man dafür und dagegen argumentieren kann und wo man auch nicht so oft tatsächlich ein Problem mit dem Singleton bekommen wird. Imo ist ein Singleton allerdings keine schöne Lösung.

Dass die Wiederverwendbarkeit von Code voller versteckter globaler Abhängigkeiten praktisch Null ist, ist euch bewusst, nehm ich mal an!?

[asc]

dot schrieb:

asc schrieb:

Sie mögen unterschiedliche Konzepte sein, doch wurden letztere in den Projekten in denen ich gearbeitet habe nicht selten für das gleiche verwendet.

Naja, das machts aber eben noch lange nicht gut oder richtig...

Stimmt.

Aber wenn man davon absieht, das ein Singleton global nur eine Instanz hält, sehe ich dennoch nur wenige Unterschiede zwischen globalen Variablen, Singletons und Funktionen die eine statische Variable zurückliefert. Von den Grundprinzip hat man bei allen 3 Ansätzen ähnliche Anforderungen: Zugriff von mehreren Stellen auf einen bestimmten Kontent, der zur Laufzeit erhalten bleibt.

dot schrieb:

asc schrieb:

z.B. für das halten einer globalen Konfiguration (mit schönen Fehlereffekten wegen Abhängigkeiten und Linkreihenfolgen die sich geändert hatten)...

Braunstein schrieb:

Wir verwenden gerade für solche globalen Konfigurationen auch Singletons.

Und mit genau welcher Begründung? Wieso genau muss um jeden Preis sichergestellt werden, dass die entsprechenden Typen hier und jetzt und für alle Zeit jemals nie mehr als einmal instanziert werden?

In unseren Programm gibt es bezogen auf eine Programminstanz genau _einen_ Benutzer, mit seinen Rechten und benutzerspezifischen Einstellungen; Bei der Programmkonfiguration sieht es ähnlich aus. Nenn mir hier den Grund warum man unbedingt mehrere Instanzen braucht.

Ob ich hier eine Funktion mit statischer Variable oder ein Singleton anbiete nimmt sich für mich überhaupt nichts. Ein Singleton ist auch nichts anderes als eine statische Variable, wenn gleich die Schnittstelle per se nur eine Instanz anbietet.

Davon abgesehen gibt es auch Singletons die zwar eine Instanz eines bestimmten Typs halten, der Typ als solches aber seperat instanziert werden kann...

[asc]

Braunstein schrieb:

@asc Aus deiner Bemerkung dazu schließe ich, dass ihr dafür jetzt keine Singletons mehr verendet. Wie macht man es dann? Mir ist hier dazu nichts besseres als Singleton (oder eben globale Variable) eingefallen.

Ich verwende weiterhin Singletons (wenn ich auch nicht sagen kann wie es in den vorherigen Firmen abläuft, hatte dort einiges zumindest auf die Variante mit der Funktion mit statischen Kontent geändert), aber versuche die Anzahl in Grenzen zu halten.

Im aktuellen Programm gibt es effektiv 4 globale Werte (unterschiedlich umgesetzt):
1. Ein Objektcache für Stammdaten [der eigentlich die DB-Zugriffe reduzieren sollte - den ich aber liebend gern entfernen würde, er macht imho mehr Ärger als er wirklich Nutzen bringt].
2. Daten zur aktuellen Anmeldung [Benutzername/Rechte]
3. Die Programmkonfiguration
4. Das VCL-Application Objekt

Nummer 2 ist definitiv als Singleton [Meyer-Singleton] umgesetzt (basiert auf meinen Mist), da ich hier keinen Grund für mehrere Instanzen sehe.

[dot]

asc schrieb:

Aber wenn man davon absieht, das ein Singleton global nur eine Instanz hält, sehe ich dennoch nur wenige Unterschiede zwischen globalen Variablen, Singletons und Funktionen die eine statische Variable zurückliefert. Von den Grundprinzip hat man bei allen 3 Ansätzen ähnliche Anforderungen: Zugriff von mehreren Stellen auf einen bestimmten Kontent, der zur Laufzeit erhalten bleibt.

Nope und ich zitiere natürlich immer gern jene schicksalhafte Seite 127, die wohl besser niemals gedruckt worden wäre:

Gof schrieb:

Use the Singleton pattern when

• there must be exactly on instance of a class, and it must be accessible to clients from a well known access point.
• ...

asc schrieb:

dot schrieb:

asc schrieb:

z.B. für das halten einer globalen Konfiguration (mit schönen Fehlereffekten wegen Abhängigkeiten und Linkreihenfolgen die sich geändert hatten)...

Braunstein schrieb:

Wir verwenden gerade für solche globalen Konfigurationen auch Singletons.

Und mit genau welcher Begründung? Wieso genau muss um jeden Preis sichergestellt werden, dass die entsprechenden Typen hier und jetzt und für alle Zeit jemals nie mehr als einmal instanziert werden?

In unseren Programm gibt es bezogen auf eine Programminstanz genau _einen_ Benutzer, mit seinen Rechten und benutzerspezifischen Einstellungen; Bei der Programmkonfiguration sieht es ähnlich aus. Nenn mir hier den Grund warum man unbedingt mehrere Instanzen braucht.

Nenn mir einen Grund, warum man mehrere Instanzen hier explizit verbieten muss. Wenn du keinen hast, gibt es auch keinen Grund für ein Singleton. Genau da liegt der Knackpunkt: "Ich brauch nur eine Instanz" -> man macht nur eine Instanz, "Es ist eine wesentliche Eigenschaft des Typs, dass es um keinen Preis der Welt jemals mehr als genau eine Instanz davon gegeben darf" -> Singleton.

Ich kann dir nur wünschen, dass du den Tag nie erleben musst, an dem in dieser Anwendung plötzlich mehr als genau ein Benutzer mit seinen Rechten und benutzerspezifischen Einstellungen existieren soll.

asc schrieb:

Davon abgesehen gibt es auch Singletons die zwar eine Instanz eines bestimmten Typs halten, der Typ als solches aber seperat instanziert werden kann...

Nein, sowas gibt es per Definition nicht. Sobald ein Typ beliebig instanziert werden kann, ist es kein Singleton mehr, genau das macht doch das Singleton aus!? (hence the Name...)

asc schrieb:

Nummer 2 ist definitiv als Singleton [Meyer-Singleton] umgesetzt (basiert auf meinen Mist), da ich hier keinen Grund für mehrere Instanzen sehe.

Wie schon oben gesagt: Es gibt einen wesentlichen Unterschied zwischen "momentan keinen Grund für mehrere Instanzen sehen" und "einen Grund gegen mehrere Instanzen sehen" und Singleton ist potentiell nur in letzterem Fall angebracht.

[asc]

dot schrieb:

Und mit genau welcher Begründung? Wieso genau muss um jeden Preis sichergestellt werden, dass die entsprechenden Typen hier und jetzt und für alle Zeit jemals nie mehr als einmal instanziert werden?

Nenn mir bitte eine Gegenbegründung, warum man für Daten die genau einmal im System existieren kein Singleton verwenden sollte. Es gibt hier ebenso keinen Zusatznutzen wenn ich eine Instanz über beispielsweise eine statische Variable in einer Funktion erzeuge und zurückgebe.

Ebenso...

dot schrieb:

asc schrieb:

Davon abgesehen gibt es auch Singletons die zwar eine Instanz eines bestimmten Typs halten, der Typ als solches aber seperat instanziert werden kann...

Nein, sowas gibt es per Definition nicht.

...gibt es mehr Farben als schwarz und weiß.

Vereinfacht, und unvollständig:

template<T>
class Singleton
{
    public:
        static T& GetInstance(); 
}

Solche Konstrukte habe ich bereits gesehen (wenn auch nicht selbst im Einsatz).

dot schrieb:

Wie schon oben gesagt: Es gibt einen wesentlichen Unterschied zwischen "momentan keinen Grund für mehrere Instanzen sehen" und "einen Grund gegen mehrere Instanzen sehen" und Singleton ist potentiell nur in letzterem Fall angebracht.

Dann nenn mir einen Fall in dem es Sinn macht das an einer Programminstanz _gleichzeitig_ mehrere Benutzer angemeldet sein müssten (Macht für mich wenig Sinn). Oder warum man die allgemeinen (für alle gültigen) Programmeinstellungen mehrfach halten muss?

Ich will nicht sagen das Singletons ideal sind, aber ich sehe hier auch keinen Zusatznutzen für die Verwendung einer wie auch immer anders gearteten globalen Instanz (globale Variable / statische Variable die man über Funktion abfragt...).