Warum sollte man eigentlich nicht generell statische Variablen nutzen? Ist es nicht so dass man Leistung spart, da die Variable nicht erst auf dem stack angelegt werden muss?

Warum sollte man eigentlich nicht generell statische Variablen nutzen?

Weils z.b. Thread safety versaut.

Ist es nicht so dass man Leistung spart, da die Variable nicht erst auf dem stack angelegt werden muss?

Da wird nix angelegt sondern nur der Stackpointer weiter geschopben

Ist es nicht so dass man Leistung spart, da die Variable nicht erst auf dem stack angelegt werden muss?

Nicht wirklich. Das Allokieren auf dem Stack kostet fast nichts (Stackpointer verschieben). Zuweisung und Initialisierung sind bei skalaren Typen gleich effizient, bei grösseren Typen meist auch ungefähr.

Statische Variablen liegen in einem separaten Speicherbereich, Werte dort zu holen/reinzuschreiben braucht auch Zeit. Zusätzlich hast du Probleme im Zusammenhang mit Multithreading, wenn eine Funktion mehrmals gleichzeitig aufgerufen wird.

Wenn du riesige Objekte konstruierst und bei jedem Aufruf nur kleine Änderungen vorkommen, können statische Variablen schon schneller sein. Allerdings ist oft eine Alternative (z.B. Klasse, die Status speichert) sinnvoller.

...Warum sollte man eigentlich nicht generell statische Variablen nutzen? Ist es nicht so dass man Leistung spart, da die Variable nicht erst auf dem stack angelegt werden muss?

"statische Variablen" klingt gut - aber wenn man sie als "globale Variablen" bezeichnet (was sie auch sind), findet man ausreichend Nachteile, die einen eventuellen Performancevorteil mehr als aufwiegen.
Einzig die Möglichkeit, den Zugriff auf Klassenfunktionen zu beschränken, ist ein Vorteil ggü. sonstigen globalen Variablen - der aber nur wenig ins Gewicht fällt.

Gruß,

Simon2.

"statische Variablen" klingt gut - aber wenn man sie als "globale Variablen" bezeichnet (was sie auch sind) [...]

Dieses Argument gilt für private statische Variablen aber nur bedingt und für funktionslokale gar nicht.

Simon2 schrieb:

"statische Variablen" klingt gut - aber wenn man sie als "globale Variablen" bezeichnet (was sie auch sind) [...]

Dieses Argument gilt für private statische Variablen aber nur bedingt und für funktionslokale gar nicht.

Das ist jetzt eine Definitionssache.
Die Unterschiede sind bloss Sichtbarkeit/Linkage und Access-Protection.
Wenn man das als wesentlich ansieht, sind statische Variablen keine globalen Variablen.

Bloss das IMO grösste Übel an globalen Variablen ist nicht dass es schnell zu Name-Clashes kommt, oder dass sie jeder ändern kann weil es keinen Zugriffsschutz gibt. Das grösste Übel ist, dass es sie nur 1x gibt, dass sie "Singletons" sind. Und das trifft auf statische Variablen in einer Funktion genauso zu.

Das grösste Übel ist, dass es sie nur 1x gibt, dass sie "Singletons" sind. Und das trifft auf statische Variablen in einer Funktion genauso zu.

Das stimmt, wobei ich den unkontrollierten Zugriff ebenfalls als grosses Problem globaler Variablen ansehe und deswegen auch eine etwas andere Definition verwende. Zumindest würde ich statische Variablen auf Klassen-, Funktions- und Namensraum-Ebene nicht in den selben Topf werfen, darum auch mein Einwand.

Natürlich abgesehen von den ganz ganz wenigen Fällen, wo es wirklich Sinn macht, ein Singleton zu haben.

Für mich ganz persönlich ist der Punkt dass sie alle "Singletons" sind, schon so schlimm, dass alles weitere keinen Unterschied mehr macht. ...

So bewerte ich persönlich das auch.
Ich wollte aber dem Threadersteller auch nicht komplett das Denken abnehmen, sondern darauf hinweisen, dass er mal unter "Nachteile globaler Variablen" nachschlagen und sich davon "inspirieren" lassen sollte.
Außerdem sind oftmals es oftmals dieselben
a) Auslöser/Problemstellungen, die einen zu statischen Variablen wie zu globalen Variablen zu drängen scheinen und
b) Lösungsansätze, die beides nicht nur unnötig, sondern a) besser lösen.

Gruß,

Simon2.