Ich habe immer wieder mühe mit Variablen ich höre immerwieder das Globale Variablen schlecht sind, aber warum?

Ich habe hier ein Problemchen.. ich versuchs mal einfach darzustellen mit pseudocode:

function initialisieren () {
lese zahl 5 aus datei XYZ und speicher in variable XY
}

nun habe ich ein function die ...:

function run () {
XY ist gleich ? 
}

ich tu jetzt das Projekt einmal initialisieren beim start, aber ich möchte natürlich nicht immer wieder diese zahl aus der Datei rauslesen und in die Variable XY speichern, sondern würds gern einfach einmal machen beim start und dann diese Variable in der Funktion "run" immer wieder zur Verfügung haben.. ich wüsste zwar das es mit globalen variablen ginge, aber dieses Problem wie oben beschrieben trifft eben noch viel zu, und irgendwie hab ich im Kopf einfach verankert das ich globale variablen meiden sollte... gibt es da ne bessere Lösung als globale Variablen?

Vielen Dank für die Antwort!

wäre das inteligenter als globale variablen? ich könnt schon die ganze zeit variablen rumschaufeln, aber naja... mit der zeit sind es dann doch relativ viele variablen die ich da rumschaufeln muss..? (jenachdem wie gross das programm wird..)

du koenntest z.b. ein singleton verwenden.
du koenntst deine 'globalen' variablen in eine struct tun, in deiner main initialisieren und nur eine referenz oder einen pointer weiter geben.
schlimmsten falls alles in eine struct und die in einem namespace als static zur verfuegung stellen

Meep Meep

Antipattern

Und hier zurecht Antipattern genannt.

Flutscherino schrieb:

ach lol genau ich könnt sie in meiner main initialisieren und mit pointer dann von dort weitergeben, lol das ich da nicht draufgekommen bin

Hä? Wo ist jetzt der Unterschied?
Wenn du uns etwas mehr Informationen gibt, können wir dir vielleicht sogar eine schöne Lösung nennen.

Wie wäre es mit Singletons?

Um welches Problem zu loesen?

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?

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

Singleton_1 schrieb:

Wie wäre es mit Singletons?

Um welches Problem zu loesen?

Zu wenige design patterns im Programm.

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

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

[...] 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*

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

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