globale Variablen vermeiden

Ich habe im Moment in meinem Programm einige globale Variablen, die ich gerne beseitigen würde.
Das Problem ist aber, das ich die Var. aber in mehreren Funktionen benötige.
Man könnte sie zwar jedesmal als Arguement übergeben, das ist ja auch nichts "richtiges".
Ein Freund der in quick-basic programmiert, meint ich suche so etwas wie "SHARED" in basic. (kA ob das stimmt, aber vielleicht hilft es)
schonmal danke im vorraus.

Maxi

Ja, also Shared in BASIC gibt es. Aber wenn du in jeder Funktion die benötigten Varibalen SCHARED setzt, kommt das selbe raus, als wären es globale Variablen. SHARED sagt nämlcih, dass die SHARED-VARIABLE von der Prozedur und von der Modul-Ebene gelesen werden kann. Also, ich finde globale VAriablen nicht schlecht, außer, wenn es natürlich jede ist...

Ich schreibe vor alle g_ und dann erkennt man das schon. Ich komme damit gut zurecht.

Gruß, Maxi

Helium

Ich kennen die genauere Sachlage nicht. wäre es vielleicht sinvoll ein Singleton zu basteln?

*Man könnte sie zwar jedesmal als Arguement übergeben, das ist ja auch nichts "richtiges".
*
Es kommt immer darauf an, brauchst du die Variablen in nahezu jeder Funktion dann ist manchmal eine globale Variable sinnvoll.
Andernfalls muss du die Variable halt mit übergeben bzw. wenn du diese auch in der Funktion ändern willst übergibst du einen Zeiger.

DasPinsch

Auch eine Methode Globale Variablen Wegzubekommen ist alles in Klassen unterzubringen!
Jedoch müssen manche Klassen dann global werden...

Daniel E.

Original erstellt von DasPinsch:
Auch eine Methode Globale Variablen Wegzubekommen ist alles in Klassen unterzubringen!

'Alle Funktionen und globalen Variablen packen wir jetzt in die Klasse "Programm"!'

DasPinsch

Original erstellt von Daniel E.:
'Alle Funktionen und globalen Variablen packen wir jetzt in die Klasse "Programm"!'

So war das nicht gemeint^^ eine klasse wäre aber zum beispiel eine inputklasse, in der alle werte aller eingabegeräte gespeichert werden

"wäre es vielleicht sinvoll ein Singleton zu basteln?"
damit habe ich noch nicht gearbeitet, aber ich werde mir das mal angucken, thx.
danke@all auch für die anderen tips wie mit dem g_ (auch wenn ich das nicht so 'mag')

dreaddy

Wenn du dein Programm in Klassen umbauen willst führt eigentlich kaum ein Weg daran vorbei das ganze völlig neu aufzubauen(Den Inhalt der Funktionen kann man ja leicht verändert meist übernehmen).
Alles andere führt aber wirklich zu dem "wir bauen eine Klasse namens Programm".
Da hab ich zwar in der Schule auch volle Punktzahl drauf bekommen, aber es wäre dann einfach nur Sinnlos

junix

Original erstellt von DasPinsch:
Jedoch müssen manche Klassen dann global werden...

Die Klasse könnte in Besitz der Klasse "Programm" sein, und alles wäre wieder im Lot (o:

Ne, im Ernst: Eine globale Klasse mit Attributen ist immernoch besser als globale variablen. (Da man ja die Variablen brav private macht und Zugriffsfunktionen bereitstellt, ist dann zum Beispiel das Implementieren von Synchronisationsmechanismen (Critical-Sections, Semaphoren, etc) einfach und schnell möglich. Auch das Implementieren von Update-Mitteilungen (wenn ein Update eines Werts stattgefunden hat) lässt sich damit schön realisieren. Diese Möglichkeiten hast du bei globalen Variablen nur begrenzt.

-junix

[ Dieser Beitrag wurde am 23.06.2003 um 08:37 Uhr von junix editiert. ]

ach, das ist alles nur Münzbiegerei

Knuddlbaer

> Synchronisationsmechanismen (Critical-Sections, Semaphoren, etc)

Hast Du dazu ein paar Links ? thx

junix

Original erstellt von Knuddlbaer:
Hast Du dazu ein paar Links ?

Ne, sorry, hab ich auch nur aus der API-Doku des jeweiligen Betriebssystems.. (also z.B. MSDN->Plattform SDK...)

-junix

Peanut

Ich benutze ab und an eine (oder identische class )

struct Settings{
  static varA;
  static varB;
  ...
}

Ich finde das OK. Wer die Daten braucht macht ein

Settings setting;

und hat alle ehemals globalen Variablen im Zugriff.

Bis dann...
Peanut

Shade Of Mine

das was du machst ist nix anderes als globale variablen, es schaut zwar 'objekt orientiert' aus, is es aber nicht...

wenn du das schon so machst, dann mach die variablen private und schreib dir get+set methoden.

bzw. fuer settings empfiehlt sich eine map (assoziativer array) wo du dann einfach

Setting.Instance().get("foo");

schreiben kannst. - man beachte den singleton.

globale variablen sind ja nicht schlecht weil sie global sind, sondern das bedeutet ja etwas:
jede funktion kann sie aendern -> seiteneffekte
jede funktion kann abhaengig von ihnen werden
jede funktion kann eine globale variable so aendern, dass die naechste funktion dann nicht mehr richtig funktioniert
eine globale variable kann jederzeit einen wert bekommen der 'ungueltig' ist, bzw. wie junix schon sagte sind Critical Sections oder aehnlich spaeter einfach nicht mehr (ohne wahnsinnigen aufwand) hinzufuegbar.

deshalb soll man globale variablen vermeiden - und global heisst nicht nur, dass die variablen im globalen namespace liegen, sondern dass sie von jeder funktion aus zugaenglich sind.

manchmal braucht man variablen die von ueberall zugaenglich sind - zB wenn man Einstellungen hat, die der user bestimmen kann (zB ueber das aussehen der dialoge, anzahl der optionen,...) - dann kann es von noeten sein, eine Settings Klasse als Singleton zu entwerfen und ueber get() oder operator[] die werte auszulesen.

es gibt sicher noch n paar andere solche situationen, und ich nehme an, dort wird die loesung wahrscheinlich aehnlich sein.

aber generell globale variablen zu haben ist boese. auch mit singletons sollte man es nicht uebertreiben, denn diese sind ja auch nur schoen bemalte globale variablen.

Spieleprogrammierer

Also Beseitigen klingt etwa so hier:

int i;
i.~int(); //löscht Variable und gibt Speicherplatz frei

Nein, mal im Ernst: Wieso löschen, was soll das bringen? Lass sie doch global, wen störts? Ist sogar Vorteilhaft.

Knuddlbaer

Hallo,

der Destruktor darf nicht vom Programmierer aufgerufen werden.

Zum Globale Variablen sind toll, schau mal hier:

http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs&faq=Global#Answ

der Destruktor darf nicht vom Programmierer aufgerufen werden.

natürlich darf er das.

HumeSikkins

'Alle Funktionen und globalen Variablen packen wir jetzt in die Klasse "Programm"!'

Ist meiner Meinung nach nicht unbedingt ein schlechter Anfang. Von da aus kann man dann ganz gut mit dem Refactoring beginnen. Mit etwas glück sieht man so leichter, wer hauptsächlich mit bestimmten Daten arbeitet und wie Operationen mit diesen zusammenhängen. Nach und nach kann man dann die Klasse Programm zerlegen und mit etwas Glück bekommt man mehrere feine, geschlossene, selbstverantwortliche und zufriedene Klassen.

@die-Singleton-Freunde
Ein Singleton ist in vielerlei Hinsicht (z.B. mit Blick auf die Lebenszeit) auch nichts weiter als eine globale Variable. Der Aufruf sieht nur lustiger aus.
Die globale Variable heißt jetzt nicht mehr globalVar sondern Singleton::Instance().
Insbesondere holt man sich mit einem Singleton-als-globale-Variable-Ersatz die selben Abhängigkeiten ins Haus. Richtig ist, dass man durch den Einsatz eines Singletons um die Initialisierungsprobleme bei mehreren Übersetzungseinheiten rumkommt. Aber wie sagt Herb Sutter so schön: "but yours is not an argument in favor of Singletons, but rather an argument against global variables"[1].

Durch das Drüberstülpen eines Singletons über globale Variablen löst man nicht das *Problem* an sich. Man flickt nur etwas an einigen hässlichen Auswirkungen rum.

Ein Singleton soll garantieren, dass es es von einer Klasse nur genau eine Instanz (oder allgemeiner nur genau k Instanzen) geben kann. Diese Einschränkung ist aber längst nicht für jede globale Variable relevant. Statt also immer sofort nach Singleton zu rufen, sollte man überlegen, ob man nicht die globale Abhängigkeit an sich bekämpfen kann.

[1]Jim Hyslop, Herb Sutter: "Once is not enough" - CUJ 03/2003

Helium

Ich habe nie gesagt, nimm ein Singleton, sondern ich habe gefragt, ob ein Singleton in der Situation eine Lösung sein könnte.

Dann ist es außerdem so, dass einige der Funktionen Member des Singletons werden, was einerseits den globalen Raum freihält und andereseits für mehr übersicht sorgen kann (muss aber nicht!!!).

Außerdem ist es einfacher ein Singleton mit seinen Membern in einem neuen Projekt zu verwenden, als ein Haufen von Funktionen zusammenzusuchen. Das sind meine erfahrungen. Vielleicht sieht es bei euch ja anders aus.