ich hab ne Frage bezüglich des switch-case statements und Variablendeklaration in diesen. Folgendes ist ja nicht erlaubt:

// Variante 1
switch (state) {
    case STATE_FIRST:
        int test = 0; // Fehler
        break;
}

Das kann man jetzt natürlich so lösen:

// Variante 2
switch (state) {
    case STATE_FIRST: {
                        int test = 0; // Kein Fehler
        }
        break;
}

Was ich allerdings optisch ziemlich hässlich finde. Vor allem weil VS die Einrückung dann immer kaputt macht (int test wird extrem weit nach rechts geschoben).

Wenn ich das so mache:

// Variante 3
int test;

switch (state) {
    case STATE_FIRST:
        test = 0; // Kein Fehler
        break;
}

würde es besser aussehen. Allerdings wird dieser Code sehr oft aufgerufen, wobei STATE_FIRST allerdings nur sehr selten erfüllt ist, die Variable test also in mehr als 99% der Fälle nicht benötigt wird.

Daher meine Frage jetzt: Ist Variante 3 langsamer als Variante 2? Also kostet so eine Variable auch dann Performance wenn sie nichtmal initialisiert wird? Oder checkt der Compiler sowas von alleine?

Schöne Grüße,
hs

switch( state )
{
    case XYZ:
    {
        int hello;
        ....
        break;
    }
    case ...
}

Zu Deinen Performazüberlegungen: Es sollte wurscht sein, wo Du Deine Variable deklariert, solange sie nicht konstruiert werden muß.

mfg Martin

switch (foo)
{
case bar:
    {
        int i = 0;
        break;
    }
}

was hälst Du davon:

Ja, auch in dem Fall schiebt VS den Code-Block leider extrem weit nach rechts...

mgaeckler schrieb:

Zu Deinen Performazüberlegungen: Es sollte wurscht sein, wo Du Deine Variable deklariert, solange sie nicht konstruiert werden muß.

mfg Martin

Aber muss theoretisch nicht trotzdem Platz für diese Variable reserviert werden?

cooky451 schrieb:

Wenn es sich wie hier um ein int (oder sonstige fundamentale Datentypen handelt) sieht der generiert Code höchstwahrscheinlich genau gleich aus. Das VS den Kram so weit nach rechts schiebt kann ich allerdings nicht nachvollziehen, bei mir sieht das ganz normal aus:

Also das int war nur ein Beispiel... Heißt also bei komplexeren Datentypen sollte man das nicht so machen?

Warum VS das macht konnte ich auch nicht herausfinden, aber ich würde auch so gerne auf die extra Klammern verzichten.

Aber muss theoretisch nicht trotzdem Platz für diese Variable reserviert werden?

Nein, solange du nicht irgendwo die Adresse der Variablen nimmst kann der Compiler da machen was er für am besten hält. Der kann die Variable z.B. ausschließlich in ein Register legen, oder falls es sich um eine Konstante handelt ganz weg optimieren. Solche Micro-Optimierungen sind meist fällig unnötig. Das kann der Kompiler praktisch immer besser. Wenn du so etwas wirklich wissen möchtest hilft ohnehin nur selber messen.

Also das int war nur ein Beispiel... Heißt also bei komplexeren Datentypen sollte man das nicht so machen?

Kommt drauf an. Wenn der Contructor Nebenwirkungen hat, kann der Compiler da die Reihenfolge möglicherweise nicht ändern.

Also das int war nur ein Beispiel... Heißt also bei komplexeren Datentypen sollte man das nicht so machen?

Genau. Variablen so lokal wie möglich machen. Gerade bei komplexen Typen wie Dateien^*.

^* Naja, std::strings in innersten Schleifen mögen auch gerne mal um eine Stufe rausgetan werden, um new/delete zu sparen.

mgaeckler schrieb:

was hälst Du davon:

Ja, auch in dem Fall schiebt VS den Code-Block leider extrem weit nach rechts...

Kann man dem das nicht abgewöhnen? Er macht das ja auch glaube ich nicht dauernd, oder? Ich arbeite nicht sehr viel mir VS und habe nur wenig Probleme dieser Art.

happystudent schrieb:

mgaeckler schrieb:

Zu Deinen Performazüberlegungen: Es sollte wurscht sein, wo Du Deine Variable deklariert, solange sie nicht konstruiert werden muß.

mfg Martin

Aber muss theoretisch nicht trotzdem Platz für diese Variable reserviert werden?

Ob der Compiler beim Eintritt 10 oder 11 Variablen auf dem Stack reserviert ist völlig wurscht. Du verschwendest zwar unter Umständen 4 Byte auf dem Stack, dafür muß der Block im switch dies nicht mehr tun, was auch wieder ein paar Byte und Taktzyklen einspart. Darüber hinaus wir befinden uns im Jahre 2014. Die Zeiten, als wir die Taktzyklen einzelner CPU-Befehle summiert haben, oder jedes einzelne Byte hinterfragt haben, sind vorbei. Ich bin kein Freund von verschwenderischer Programmierung, aber das habe ich mir schon lange wieder abgewöhnt.

Bei meinem ersten Computer wurde die Kapazität noch in Byte gemessen. Ich mußte mir einen Centronicstreiber schreiben und der durfte nicht mehr als 128 Byte groß sein. Der Stack der CPU hatte eine maximale Größe von 256 Byte. Damals wurde jeder Taktzyklus und jedes einzelne Byte hinterfragt.

mfg Martin