Schleifen



  • Gibt es einen Unterschied zwischen folgenden Statements, respektive einen Grund eines von beiden vorzuziehen?

    // Statement A:
    while ((++a)->value > 0);
    
    // Statement B:
    while ((++a)->value > 0) {}
    


  • Nope, gibt keinen und wenn es eine gäbe würde er weg optimiert 😉
    Ich bevorzuge Variante A mit dem Semikolon in der nächsten Zeile.



  • Semicolon in der nächsten Zeile gefällt dem Google Style Guide garnicht...



  • Ich würde eher an sowas denken:

    do
       ++a;
    while(a->value > 0)
    


  • Das kommt auch auf den Zusammenhang an bzw. der Zusammenhang ist's, auf den es doch auch ankommt, bzw. auf den Zusammenhang kommts an, auch, oder doch nicht? 😉



  • Tomahawk schrieb:

    Semicolon in der nächsten Zeile gefällt dem Google Style Guide garnicht...

    Bestimmt Google jetzt wie man programmiert?



  • WerIstGoogle schrieb:

    Tomahawk schrieb:

    Semicolon in der nächsten Zeile gefällt dem Google Style Guide garnicht...

    Bestimmt Google jetzt wie man programmiert?

    Noch nicht direkt, aber man sollte sich doch mit der zukünftig einzigen Supermacht gut stellen. Zudem muss man sich dann auch nicht umgewöhnen, wenn der Styleguide Gesetz wird.



  • das is ja lächerlich, ehrlich... ich programmiere, solange keine performence-
    einbusung (bussung|bußung; wie jetzt?) eintritt, so wie es mir beliebt. ob ich
    jetzt

    Tomahawk schrieb:

    // Statement A:
    while ((++a)->value > 0);
    

    oder

    Tomahawk schrieb:

    // Statement B:
    while ((++a)->value > 0) {}
    

    schreibe is daher egal, vorab die compiler (nicht alle) solche dinge wegoptimieren



  • Was gäbe es denn da genau wegzuoptimieren?



  • ach vergessen was anzufügen: wenn es etwas weg zu optimieren gibt...



  • Tomahawk schrieb:

    Gibt es einen Unterschied zwischen folgenden Statements, respektive einen Grund eines von beiden vorzuziehen?

    // Statement A:
    while ((++a)->value > 0);
    
    // Statement B:
    while ((++a)->value > 0) {}
    

    Jetzt weiß ich nicht über die Typisierung Bescheid, aber eigentlich wäre

    while ((++a)->value);
    

    völlig ausreichend. Damit betrittst Du aber die "dunkle Seite der Macht" oder "obfuscative coding".
    So 'nen Kram zusammenramschen ist Aufgabe des Compilers, nicht Deine.



  • Nein, das ist nicht ausreichend. Die Ursprungsversion wird zu FALSE ausgewertet, wenn value kleiner oder gleich 0 ist.
    Bei Deinem Vorschlag wird nur dann zu FALSE ausgewertet, wenn value gleich 0 ist; sollte value kleiner als 0 sein, ergibt Dein Code ein anderes Verhalten.



  • Belli schrieb:

    Nein, das ist nicht ausreichend. Die Ursprungsversion wird zu FALSE ausgewertet, wenn value kleiner oder gleich 0 ist.
    Bei Deinem Vorschlag wird nur dann zu FALSE ausgewertet, wenn value gleich 0 ist; sollte value kleiner als 0 sein, ergibt Dein Code ein anderes Verhalten.

    Bitte lesen vor posten. Kann je nach Typisierung alles oder nix ausmachen. Tomahawk ist einer, der sich schon einen Reim drauf fertigen kann.



  • Ich hab das schon gelesen, und

    pointercrash() schrieb:

    Tomahawk schrieb:

    Gibt es einen Unterschied zwischen folgenden Statements, respektive einen Grund eines von beiden vorzuziehen?

    // Statement A:
    while ((++a)->value > 0);
    
    // Statement B:
    while ((++a)->value > 0) {}
    

    Jetzt weiß ich nicht über die Typisierung Bescheid, aber eigentlich wäre

    while ((++a)->value);
    

    völlig ausreichend.

    ist einfach falsch.
    Daran ändert auch Deine Verwendung von so nichtssagenden Wörtern wie 'eigentlich' und 'völlig' nichts, oder willst Du damit zum Ausdruck bringen, daß es uneigentlich dann doch nicht ausreichend, oder aber zwar ausreichend, aber nicht völlig ausreichend ist?



  • Wenn man davon ausgeht das nur ein Interval von 0..n abgedeckt werden soll, wobei n > 0 , dann kann man durchaus auf != 0 prüfen, falls a eine Ganzzahl ist. Ansonsten wäre das sehr riskant.



  • belli hat recht, auch wenn üblicherweise die Zahlenmenge N oder R+ verwendet wird
    und nicht im gesammten R (bzw. Q)... wird jedoch (nur so angenommen) die
    Zahlenmenge Z verwendet und die laufvariable ist (aus was für einem grund auch
    immer) -2, so entsteht eine endlos schleife. wobei hier in diesem beispiel, im
    falle des falles, das der letzte wert eine minus zahl ist, ein ReadAcces Fehler
    (oder so ähnlich halt ^^), sprich sowas in der art: Have no Access to read at 0x00000000

    da er den wertebereich überschreiten kann, aber nicht dürfte



  • Ich verstehe diese ReadAcces Fehler Geschichte nicht. Es geht hier um den Wertebereich von value, nicht um den von a ... dass in beiden gültige Werte stehen, davon gehen wir mal aus. Wir wissen aber eben nicht, welchen Wertebereich value hat.



  • nachja, wenn a 10 gross ist und a[9]->value == -1 dann würde a wieder um
    eines erhöht was dann entspricht: a[10]->value, aber a[10] gibt es nicht bzw.
    es wird auf ein speicherbereich zugegriffen der entweder geschützt oder schon
    reserviert ist. =b

    BSP:

    while((a++)->value); // a maximal 10, bzw. index 9

    1. Durchgang: a=0, a->value = 12
    2. Durchgang: a=1, a->value = 9
    3. Durchgang: a=2, a->value = 7
    4. Durchgang: a=3, a->value = 2
    5. Durchgang: a=4, a->value = 3
    6. Durchgang: a=5, a->value = 123
    7. Durchgang: a=6, a->value = 122
    8. Durchgang: a=7, a->value = 13
    9. Durchgang: a=8, a->value = 4
    10. Durchgang: a=9, a->value = -2
    11. Durchgang: a=10, a->value --> Keine Berechtigung zum Lesen bzw. Index überschritten
    

    weiteres sollte doch a++ und nicht ++a stehen, weil sonst wird a[0] nicht behandelt wird?
    oder lieg ich falsch?



  • Okay, ich glaube, ich habe verstanden, was Du meinst. Aber genau darum geht es ja auch die ganze Zeit, wenn value negativ sein kann, dann wird unter Umständen die Schleife nicht bzw. einem anderen Zeitpunkt abgebrochen, wenn man das '> 0' weglässt. Ein Zugriffsfehler wäre da ja noch das Wünschenswerteste, den bekommt man ja mit, schlimmer ist es dagegen, wenn das Programm nicht abstürzt, sondern mit fehlerhaften Parametern weiterläuft, und entweder fehlerhafte Ergebnisse erzeugt, oder als Folge der fehlerhaften Abbruchbedingung erst viel später an einer anderen Stelle abstürzt - dann ist es nämlich häufig nicht so einfach, die Fehlerursache aufzuspüren.



  • stimmt schon, aber die access-geschichte ist eine meiner häufigsten Fehler-
    quellen. weiss ja nich wie es euch so geht, aber bei mir is das halt so, liegt
    wohl daran das mir noch die erfahrung fehlt...


Log in to reply