for Schleife ?



  • Hi Leute

    for (int i=1; i<zeilen-1; i+6)//i soll nach jedem Schritt um 6 angehoben werden
    

    Ist sowas möglich ?

    Gibt das ein Problem wenn zeilen = 2 ist ?

    Wenn nicht wie kann ich es dann machen ?

    THX Fleedo



  • Da besteht so kein problem. Das wird denk ich ohne weiteres klappen. Wenn zeilen = 2, dann ist die Bedingung nur im 1. Fall erfüllt, und nach dem ersten durchlauf, wenn 6 dazu addiert werden, ist die schleife schon beendet, da i jetzt 7 ist.

    Edit: (peinlich peinlich) 1+6 != 8 😃



  • Das funktioniert aber nur so:

    for (int i=1; i<zeilen-1; i+=6)
    


  • Hi

    THX werds so probieren !!!

    Fleedo



  • Ich möchte da mal eine grundsätzliche Diskussion auslösen:

    for( int i=1; i<zeilen-1; i++  ) // Var.1
    for( int i=1; i<zeilen-1; ++i  ) // Var.2
    for( int i=1; i<zeilen-1; i+=1 ) // Var.3
    

    Wenn ich das richtig verstanden habe, sind Var. 1 und 2 gleichwertig. Manchmal findet man auch Var. 3. Ich bevorzuge inzwischen Var. 2, weil man Präinkrement vor Postinkrement präferieren sollte.
    Var. 3 sollte auch o.k. sein, wenn es auch seltsam aussieht.
    Wie seht ihr das?



  • Wie seht ihr das?

    Bist du wieder besoffen oder was soll diese komische Frage? 🙄 🙄



  • ... sonst noch Kommentare? :p



  • Funzen tun alle Varianten, aber Var. 2 ist die schnellste.



  • wie kommst du auf die Idee zweite Variante sei die schnellste? Hier ein Auszug aus dem was VC7.1 produziert:

    int a = 0, b = 0;
    a++, ++b;
    
    __asm inc a;
    
    ;Initialisierung
    mov         dword ptr [a],0		
    mov         dword ptr [b],0 
    
    ;erste Variante
    mov         eax,dword ptr [a] 	
    add         eax,1 
    mov         dword ptr [a],eax
    
    ;zweite Variante
    mov         ecx,dword ptr [b]	
    add         ecx,1 
    mov         dword ptr [b],ecx 
    
    ;Inline Assembler
    inc         dword ptr [a]
    

    es könnte auch an VC7.1 liegen 🙄 :p



  • na endlich mal einer, der begriffen hat, dass Compiler heutzutage etwas intelligenter sind als anno 1970. In der Tat optimiert ein Compiler (bzw. die Optimierstufe des Compilers) den Code heute so hoch, dass man nicht annähernd sein listing in einer Hochsprache wiedererkennt...

    -junix



  • btw: Auch MSVC 6sp5 generiert schon folgenden code:

    ; Als Kommentare jeweils die C-Codes dazu
    
    ; int a = 0;
    mov dword ptr [ebp-8], 0
    ; int b = 0;
    mov dword ptr [ebp-0Ch], 0
    
    ; a++;
    mov eax, dword ptr [ebp-8]
    add eax, 1
    mov dword ptr [ebp-8], eax
    
    ; b++;
    mov ecx, dword ptr [ebp-0Ch]
    add ecx, 1
    mov dword ptr [ebp-0Ch], ecx
    

    Ist zwar grundsätzlich compilerabhängig, was daraus jeweils gemacht wird, aber alle aktuellen Compiler sind schon hochoptimierend... *hrm* (o: (nur so als Ergänzung *g*)

    -junix

    [edit]was mich allerdings wundert, ist, dass er nicht direkt inkrementiert.. hmm wär jetzt spanned was der intel-compiler daraus wurschtelt.[/edit]



  • gcc 3.2.2 erzeugt schon ohne Optimierung bei ++i, i++, i+=1 und i=1+i denselben code:

    leal    -4(%ebp), %eax
    incl    (%eax)
    

    (edit: [ code ] rückt irgendwie falsch ein 😕 )



  • Naja, solche simplen Optimierungen kann selbst ein vorsintflutlicher Compiler bei Builtins vornehmen. Aber nichts desto trotz sollte man sich ++i angewöhnen um bei Objekten bei denen der Compiler nicht optimiert nicht einfach aus Gewohnheit postincrement zu verwenden.



  • Was spricht gegen das Post increment?



  • Beim Postinkrement muss erst eine temporäre Variale angelegt werden, die den alten wert speichert und zurück gibt.



  • OT:
    Wenn das Post-Increment über das Pre-Increment implementiert ist, und zwar so:

    inline const A A::operator++(int)
    {
      A old = *this;
      ++(*this);
      return old;
    }
    

    Darf der Compiler die Erstellung und Kopie der Variablen old komplett entfernen, wenn er feststellt, dass der Rückgabewert von operator++ nicht verwendet wird?



  • nur bedingt!
    Der Copy-Konstruktor könnte seiteneffekte haben.



  • Return value optimization entfernt z.B. auch Copy-Konstruktor Aufrufe. Aufrufe des Copy-C'tor werden also nicht garantiert.
    Allerdings funktioniert return value optimization nur bei temporären Objekten, was hier nicht zutrifft.

    Wie ist das in diesem Fall?



  • Er darf die Kopie beim zurückgeben von old wegoptimieren (NRVO), aber nicht die Erzeugung von old.



  • (edit: [ code ] rückt irgendwie falsch ein 😕 )

    du meinst die erste Zeile? mach einfach einenPunkt in die Erste Zeile und fang erst ab der zweitzen an zu schreiben.


Anmelden zum Antworten