Warum verwendet man die Speicherklasse static nicht immer, wenn man in einer .cpp Unit Globale Variablen verwendet, ausser man ist sich natürlich sicher, dass man die Globale Variable auch extern nutzen möchte. Das macht für mich einfach keinen Sinn. Denn ich sehe es oft oder gar immer im Gegenteil.

static ist doch eigentlich nur ein Hinweis an den Compiler, also auf den Assembler Code hat static garkeine Auswirkung, wie jetzt z.B. das Schlüsselwort int oder char. Dort macht gibt es natürlich (technisch gesehen) Auswirkungen. Also: Warum nur, wird static bei globalen Variablen kaum verwendet?

• Im Namensraum: Gegenstück zu extern, beeinflusst "linkage" (external linkage -> internal linkage)
• Klasse: für "statische" Elementfunktionen (Funktionen, die keinen this-Zeiger brauchen und ohne Objekt aufgerufen werden)
• Im Funktionskörper: für Deklaration von Variablen mit "statischer" statt "automatischer" Speicherklase

Die Idee von anonymen Namensräumen ist die, "static" für den ersten Fall zu ersetzten. Mit Speicherklassen hat das nichts zu tun. "Linkage" (zu Deutsch Bindung) beeinflusst die Sichtbarkeit von Deklarationen zwischen versch. Übersetzungseinheiten.

Gruß,
SP

Globale Variablen und Funktionen sind immer statisch. Es wäre unnötig und redundant da noch ein static hinzuschreiben.

Oh, Du hast Recht! Aber ist es denn nicht möglich genau das zu erreichen, was ich damit eigentlich bezwecken wollte? So muss man ja sehr aufpassen, wie man seine Globalen Variablen benennt.

Globale Variablen und Funktionen sind immer statisch.

Ne, definitiv nicht. Du kannst wunderbar Name-Clashes erzeugen.

static_magic schrieb:

P.S. Was ist wenn ich in zwei verschiedenen .cpp Units gleichnamige Globale Variablen einsetze und in einer dritten dann ein extern verwende? Welche wird dann vom Compiler verwendet?

IMHO:
Falls beide statisch sind => Keine, Linkerfehler.
Falls eine der beiden statisch ist => Die nicht-statische
Falls beide nicht statisch sind => Linkerfehler, Mehrfachdefinition

Weil genau das ergibt den Effekt, das wenn dann eine der Variable statisch ist, kein zugriff ausserhalb der Unit möglich ist.

Badestrand: Dein IMHO zeigt aber eigentlich das mein erstes Posting doch stimmt

Weil genau das ergibt den Effekt, das wenn dann eine der Variable statisch ist, kein zugriff ausserhalb der Unit möglich ist.

Äh ja, genau! Ich weiß auch nicht, warum das so wenig verbreitet ist. Na gut, anonyme Namespaces gibt's manchmal (die ja quasi alles innerhalb "static" setzen). Ich deklariere jedenfalls immer schön als internal-linkage wenn nicht explizit anders gebraucht.

edit:

Also einfach gesagt sind Globale Variablen standard mässig statisch, wenn nun aber mehrere gleichnamige vorkommen, werden die mit static gekennzeichneten Variablen für den Zugriff ausserhalb der Unit unzugänglich, oder?

Also soweit ich weiß sind statische globale Variablen/Funktionen immer unzugänglich von außen.

drakon schrieb:

Globale Variablen und Funktionen sind immer statisch. Es wäre unnötig und redundant da noch ein static hinzuschreiben.

Oh, Du hast Recht!

Vorsicht: Die Bedeutung von static ist überladen, wie ich schon erwähnte. Du schmeißt Speicherklassen (storage class) mit Bindung (linkage) durcheinander.

Gruß,
SP

Also einfach gesagt sind Globale Variablen standard mässig statisch

Bullshit. Sie haben standardmäsig nur eine statische Speicherklasse. Das hat aber mit "static" nichts mehr zu tun. (!!!)

Gruß,
SP

Also sind Globale Variablen nicht automatisch Statisch sondern eher Auto. Jemand anderer Meinung?

Wahrscheinlich meinte drakon genau das (also auto-Speicherklasse), hat aber kurz die semantischen Unterschiede von static durcheinandergeworfen.

Genau.

Allerdings muss ich zugeben, dass ich static für die linkage nie gebraucht habe und mir dessen gar nicht mehr bewusst war.

int i;

eine Statische Lebenszeit hat, aber nicht static ist? Oder verwechsle ich da jetzt etwas.

Sebastian ja das stimmt was Du da schreibst, dem bin ich auch im Bilde. Ich habe zum anfang den Begriff "Speicherklasse" verwendet, weil das Schlüsselwort static nunmal auch dazu gehört.

drakon: Also meintest du eigentlich nur das eine Globale Variable die wie folgt deklariert wurde:

int i;

eine Statische Lebenszeit hat, aber nicht static ist? Oder verwechsle ich da jetzt etwas.

Ja, genau. Mir war nicht mehr klar, dass static als linkage specifier ebenfalls eine Verwendung hat. Tut mir leid, wenn ich dich da verwirrt habe.
Ich denke, dass das Standardisierungskomitee guten Grund hatte dieses Sprachmittel als "Missbilligt" zu handeln.

BTW: Falls hier namespace als Alternative gemeint ist, finde ich das auch viel besser. Allerdings muss ich sagen, für wenige Variablen finde ich static besser, um einen Scope zu erzeugen.

Nicht?

Hey ist doch kein Problem. Ich wollte hier aber auch niemand angreiffen oder so!

BTW: Falls hier namespace als Alternative gemeint ist, finde ich das auch viel besser. Allerdings muss ich sagen, für wenige Variablen finde ich static besser, um einen Scope zu erzeugen.

Nicht?

Wie gesagt mir war die ganze Problematik gar nicht bewusst, weil ich das gar nie brauche.. Aber wenn, würde ich troztdem zum namespace tendieren. Einfach, weil es viel verständlicher ist, was man vorhat.

...Globale Variable...
int i;

Objekte, die auf Namensraumebene definiert bzw deklariert werden, besitzen immer eine statische Speicherklasse. In Deinem Fall ist es eine Definition mit externer Bindung. Andere Beispiele:

static int j;         // Definition,  interne Bindung
const int k=2;        // Definition,  interne Bindung
extern int l;         // Deklaration, externe Bindung
extern const int m;   // Deklaration, externe Bindung
extern const int n=3; // Definition,  externe Bindung

Gruß,
SP

Wie gesagt mir war die ganze Problematik gar nicht bewusst, weil ich das gar nie brauche.. Aber wenn, würde ich troztdem zum namespace tendieren. Einfach, weil es viel verständlicher ist, was man vorhat.

Wenn ich eine static Variable in einer Datei sehe, macht es *PLING* und ich weiss sofort:
Diese Variable ist nur innerhalb dieser Datei sichtbar.
Damit ist es klar, was man damit vorhat.
MfG,
k.w.k.