Globale Variablen immer umgänglich?

Sind globale Variablen immer umgänglich?

Walli

Prizipiell schon, aber es gibt halt auch Fälle in denen sie Sinn machen. Man sollte nicht pauschalisieren, dass sie böse sind, aber trotzdem vor übermäßiger und sinnloser Verwendung warnen.

Sovok

aber n container mit allen globalen variablen is auf jeden fall vorzuziehn
schon allein des sauberen resets wegen

Shade Of Mine

Sovok schrieb:

aber n container mit allen globalen variablen is auf jeden fall vorzuziehn
schon allein des sauberen resets wegen

Erklärung was du damit meinst + Begründung bitte.

Also ich finde ein globales cout recht praktisch...

Helium

Wo ist die Grenze?

int a; // klar global

namespace Foo {
   int a;  // auch noch recht klar global
}

class Bar {
   static int a;  // hier könnte ich mir schon erste Streits vorstellen
};

int Bar::a;

int & baz ()
{
   static int a;  // was ist jetzt?
   return a;
}

Jester

Ich glaube, er meint man sollte lieber ein struct oder sowas definieren, in dem alle globalen Variablen drinstehen.

struct Globals
{
int status;
// ...
};

Dann hat man wenigstens einen zentralen Ort, wo die globalen Variablen deklariert werden. Das vereinfacht den Reset sicherlich enorm, weil man nicht so leicht ne Variable vergißt beim alles zurücksetzen.
Wenn die globalen Variablen auch noch über den kompletten Source verteilt sind wird's nämlich ganz übel.
Allerdings stellt sich die Frage, warum man das dann nicht in ne Klasse umbenennt (z.B. Application) und ihr die Reset-Funktionalität einbaut etc.

MfG Jester

Helium

struct Globals 
{ 
int status; 
// ... 
};

Und woher bekomme ich die Instanz? Es kann mehrere geben. Und genaus das will ich nicht. Ich könnte natürlich aus deiner struct ein Singleton bauen, aber das wäre hier vermutlich irgendwie ungeeignet. Was willst du also damit sagen?

Jester

Helium schrieb:

Und woher bekomme ich die Instanz? Es kann mehrere geben. Und genaus das will ich nicht. Ich könnte natürlich aus deiner struct ein Singleton bauen, aber das wäre hier vermutlich irgendwie ungeeignet. Was willst du also damit sagen?

Komm, Du brauchst Dich ned dumm zu stellen.

extern Global global; in den Header und gut is.
Jetzt hab ich nämlich nur noch eine globale Variable...

und ich will damit eigentlich garnichts sagen. Ich habe nur versucht zu erklären, was Sovok meint. Daß man direkt ne Klasse draus machen könnte habe ich weiter oben geschrieben.

Achja, daß Du da nicht mehrere Objekte davon haben willst ist schön. Aber das ist keine Begründung. Warum also?
Wenn alle mit global.var arbeiten, dann kümmern weitere Objekte der Sorte ja nicht. Man könnte sie zum abspeichern und verwalten des Zustands der Applikation zu bestimmten Zeitpunkten verwenden. Alternativ wäre natürlich auch ein Memento möglich. Auch im Mehrbenutzerbetrieb ist ein Singleton möglicherweise mehr hinderlich, als nützlich.

MfG Jester

Jester

@Helium, 1.Beitrag:

Zwischen den beiden ersten Alternativen und dem Rest gibt es einen bedeutenden Unterschied. An nahezu jeder Stelle im Source können neue Variablen zur Sammlung hinzugefügt werden (namespaces sind ja offen).
Bei den Klassen bin ich immerhin dazu angehalten meine Variablen da dazuzuschreiben, sodaß ich eine zentrale Stelle im Source habe, die das verwaltet.
Und genau das ist auch der Punkt, den Sovok aufzeigen wollte.

MfG Jester

Helium

Quark. Warum sollte ich Dinge zusammenfassen wollen, die gar nicht zusammen gehören. Ich gruppiere nach semantischen Aspekten, nicht nach synthaktischen!

Jester

Wenn Variablen in einem Programm als global in Frage kommen, dann hängen diese oftmals miteinander zusammen. Wenn eine Variable global ist, dann heißt das sie wird nahezu überall benötigt. Wo soll ich sie denn dann hingruppieren?
Hast Du eigentlich einen Schrank oder ein Regal in Deinem Zimmer, in dem sich möglicherweise verschiedene Sachen befinden? Warum bewahrst Du sie zusammen im selben Behältnis auf?

Abgesehen davon hier nochmal der Hinweis für Dich: Ich halte nicht viel von globalen Variablen und vermeide diese auch wo es vernünftig geht.
Ich habe nur versucht Sovoks Idee zu verdeutlichen, die auch nicht so schlecht ist. Wenn man schon globale Variablen hat, dann sollte man versuchen sie in größeren Paketen zusammenzufassen.

MfG Jester

P.S.: syntaktisch schreibst man ohne th

Helium

Wenn eine Variable global ist, dann heißt das sie wird nahezu überall benötigt.

Dein Projekt hat 200 Module und in einem Teil des Projekts brauchst du ein bestimmtes Objekt, sagen wir in 17 Modulen, also weit davon entfernt, dass sie nahezu überall benötigt wird. Was machst du?

Hast Du eigentlich einen Schrank oder ein Regal in Deinem Zimmer, in dem sich möglicherweise verschiedene Sachen befinden? Warum bewahrst Du sie zusammen im selben Behältnis auf?

Nö, mein Schrank und meine Regale sind eigentlich recht sauber aufgeräumt (im Gegensatz zu meinem Schreibtisch ). Da wo die Bücher stehen, stehen nur Bücher, etc.

Wenn man schon globale Variablen hat, dann sollte man versuchen sie in größeren Paketen zusammenzufassen.

Vielleicht nochmal überdenken: Sind diee "Vraiablen" vielleicht nur Implementierungsdetails eines Objekts, das global verfügbar sein soll und ich war nur schluderig?

syntaktisch schreibst man ohne th

stimmt.

Shade Of Mine

Von künstlichem Zusammenfassen halte ich garnix.

Was habe ich von
global.foo;
anstatt
foo;
oder global::foo;
?

Ich nur den Nachteil, dass aufeinmal alle Modul voneinander abhängig sind.
Man nehme an, dass ich im Hintertupfing-Modul eine globale Variable brauche - und schwupps muss ich alles neu kompilieren - obwohl die meisten Module nichtmal wissen was 'Hintertupfing' ist.

junix

Das Problem an globalen Variablen ist doch ganz klar, dass man keine chance hat den Zugriff darauf zu kontrollieren bzw. u.U. zu synchronisieren.

Nehmen wir z.B. Document/View. Wenn ich einfach einen globalen String unterhalte, wo jedes View ein Bischen reinschreibt und ein Wenig löscht, dann ist die Applikation mehr als nur schlecht zu Programmieren: Woher sollen die restlichen Views auch wissen, wann sie sich zu synchronisieren haben? Was ist, wenn sich zwei Views gleichzeitig ändern (bzw. in einem MVC Modell der Controller und das View etwas zu ändern haben?) etc. pp.

Mache ich den String allerdings in einer globalen Document Klasse mittels Zugriffsfunktionen greifbar, so habe ich zwar immernoch ein globales Element, allerdings die volle Kontrolle über dessen Datenelemente und wann sie wie verändert werden.

Und was hier aufgeführt wurde vonwegen alle Module untereinander abhängig, so hat man diesen Effekt mit globalen Variablen ebenso.

-junix

Sovok

obs nun global für alle module is, für ein paar oder nur für eins
ich halte bloß nix davon irgendwo im code bool bBlahEinBool=false; zu schreiben

lieber

class globModuleNameOrModuleGroup
{
public:
static void Reset();
static...
private:
static...
};