was macht der com piler aus if(0)

ANGs_Pino

Code ist:

if(0){

//Anweisungen

}else{

//mehr Anweisungen

}

mir ist klar, dass er nur ins else springt. aber was macht der compiler? schmeißt er den code nach if(0) sofort weg und überprüft die Bedingung die oder wird bei jedem durchlauf geschaut ob 0 nicht doch irgendwann mal true sein könnte...

Greetz,
ANGs_Pino

drakon

wird bei jedem durchlauf geschaut ob 0 nicht doch irgendwann mal true sein könnte...

Falls sich mal die Mathematischen Gesetzgebungen ändern, oder wie?

Der Compiler darf das wegoptimieren, falls sich das Programm sich im Verhalten dadurch nicht verändert. (Was er mit grosser Wahrscheinlichkeit auch macht).

Bashar

Das hängt vom Compiler und den dort implementierten Optimierungen ab. Konstante Bedingungen zu erkennen und unerreichbare Zweige wegschneiden ist eine sehr einfache Optimierung, die in allen praktisch eingesetzten Compilern implementiert sein dürfte. (Weiß jemand, was mit MSVC(6?) Standard ist, der soll ja keinen Optimierer haben?)

Ohne Optimierung würde in der Tat jedesmal geprüft werden, ob 0 true ist.

hustbaer

Weiß jemand, was mit MSVC(6?) Standard ist, der soll ja keinen Optimierer haben?

Der Optimizer wurde bei der Standard-Edition von VC6 "gesperrt", ja, das ist richtig.
D.h. er wird zumindest den Code im "if-Teil" im Programm-File stehen lassen, und vermutlich sogar den Vergleich.

bgdnoy

Der Compiler darf das wegoptimieren, falls sich das Programm sich im Verhalten dadurch nicht verändert.

Ein Beispiel, wo er das nicht darf, ist dieses (naheliegende):

int main(void)
{
    if (0) {
dumme_idee:
        printf("if-Block\n"); fflush(stdout);
    } else {
        printf("else-Block\n"); fflush(stdout);
        goto dumme_idee;
    }
    return 0;
}

Könnte man eigentlich mit longjmp/setjmp in den if(0)-Block reinspringen?

SG1

Naja, zuerst muss man irgendwie anders dahinkommen, um das setjmp aufzurufen. Aber dann geht's.

Bashar

Gehen wir die Fälle mal durch:

goto-Label im if(0)-Zweig
Im Zwischencode gibt's eh keine if-Anweisungen mehr, nur noch bedingte und unbedingte Sprünge. Die Bedingung 0 wird also wegoptimiert, aus dem bedingten Sprung wird ein unbedingter Sprung zum else-Zweig. Aber der then-Zweig ist durch einen anderen Sprung (über das goto) noch erreichbar, kann also nicht weggeschmissen werden.
longjmp/setjmp
Auf den ersten Blick schwieriges Problem, weil der Kontrollfluss nicht explizit sichtbar ist, sondern in Library-Funktionen steckt. Der Compiler darf seine Library aber kennen und longjmp/setjmp in seine Kontrollflussüberlegungen mit einbeziehen.