static

HumeSikkins

Der Code läuft ohne Probleme durch MS VC++ Version 6, selbst bei Warnstufe 4. Was stört Dich denn genau?

Qualifizierung der Member ist innerhalb der Klassendefinition nicht erlaubt.
So wäre's richtig:

class X
{
private:
    double wert;
    static int anzahl;
public:
    X();
    ~X();
    double getWert();
    void setWert(double z);
    static int getAnzahl() { return anzahl; }
};

Warum muss bei static-Klassenvariablen Definition und Initialisierung streng verbunden werden?

Das ist nicht bei static-Klassenvariablen so, dass ist *immer* so. Eine *Initialisierung* ist *immer* auch eine *Definition*. Es gibt keine Initialisierung ohne Definition. Initialisierung heißt Definition + Anfangswertzuweisung. Und obwohl in Anfangswertzuweisung das Wort "zuweisung" auftaucht, ist bei einer Initialisierung *keine* Zuweisung involviert.

extern int a;      // nur Deklaration
int a;             // Deklaration + Definition
int a = 22;        // Deklaration + Initialisierung
extern int a = 22; // Deklaration + Initialisierung. a wird also auch *definiert*

Innerhalb der Klassendefinition wird deine statische Member-Variable deklariert. Bei ihrer Definition muss wie bei jeder Definition ihr Typ erneut auftauchen. Das selbe gilt z.B. auch für extern-deklarierte Variablen. Ihre einzige Definition geschieht auch immer unter Angabe ihres Typs.

Bashar

Man könnte auch sagen, dass Foo::Bar = 0; eine Anweisung ist, und die sind nur in Funktionen erlaubt. Man kann übrigens ausnutzen, dass static-Variablen automatisch mit 0 initialisiert werden (bzw. dem Default-Konstruktor): int Foo::Bar;

HumeSikkins

Man könnte auch sagen, dass Foo::Bar = 0; eine Anweisung ist, und die sind nur in Funktionen erlaubt

Ja das könnte man natürlich auch. Und alles wäre dann gleich soviel einfacher

Erhard Henkes

Soweit klar. Nur der entscheidende Punkt nicht.

HumeSikkins

Nur der entscheidende Punkt nicht

Und das ist welcher nochmal?

Erhard Henkes

Frage hat sich eigentlich erledigt. Ich habe statische Klassenvariablen mit lokalen Variablen verglichen, das sollte man nicht machen. Der Unterschied ist offenbar, dass lokale Variablen nicht automatisch mit 0 initialisiert werden. Bei statischen Klassenvariablen oder globalen Variablen erfolgt dies jedoch automatisch durch den Compiler mit dem Wert 0. Warum gibt es eigentlich diesen Unterschied, oder ist dies compilerabhängig? (hier: MS VC++ 6)

#include <iostream>
using namespace std;

class X
{
public:   static int anzahl;
};

int X::anzahl; // =0;

int anzahl;    // =0;

int main()
{
   int var;
   cout << var << endl; // irgendeine Zahl
   var = 5;
   cout << var << endl; // 5

   cout << X::anzahl << endl; // 0
   X::anzahl = 3;
   cout << X::anzahl << endl; // 3

   cout << anzahl << endl;  // 0
   anzahl = 7;
   cout << anzahl << endl;  // 7

   cin.get();
   return 0;
}

[ Dieser Beitrag wurde am 03.07.2003 um 04:22 Uhr von Erhard Henkes editiert. ]

HumeSikkins

Warum gibt es eigentlich diesen Unterschied

Annahme A:
Globale und statische Variablen werden nur genau einmal initialisiert. Lokale Variablen müssten aber jedes mal wenn ihr Scope betreten wird (potentiell sehr oft) initialisiert werden. Nun braucht aber nicht jeder eine Default-Initialisierung. Jeder müsste aber dafür zahlen. Das würde das zero-cost Prinzip von C++ verletzen.

Annahme B:
Im Gegensatz zu C kann man in C++ lokale Variablen überall in einer Funktion definieren. Man definiert sie am Besten so spät wie möglich, also dort wo man sie braucht und wo man gute Startwerte für sie hat.
Würden lokale Variablen nun automatisch initialisiert werden, würden häufig unnötige Initialisierungen durchgeführt werden. Das wiederum ist nicht im Sinne von C++.

Klingt einleuchtend, habe ich bisher nirgends so gefunden.
global/statisch mit 0, lokal nicht initialisieren: Ist dieses Verhalten fest im Standard vorgeschrieben, oder hat hier jeder Compiler Freiheiten? Bei MS VC++ 6 und bei DJGPP ist es so, das habe ich getestet. Gibt es C++-Compiler, die hier anders agieren?

HumeSikkins

global/statisch mit 0, lokal nicht initialisieren: Ist dieses Verhalten fest im Standard vorgeschrieben

Yep. Genauer beschrieben steht es in 3.6.2 "Initialization of non-local objects"

Erhard Henkes

Thanks a lot.