Wieso gibt es in den gängigsten Programmiersprachen kein For-Schleifen Konstrukt, dass die Zählvariable am Ende sichert?



  • Wenn man den letzten Wert der Variable i außerhalb des for Blocks verwenden möchte, dann muss man ihn innerhalb der Schleife jedes mal sichern, auch dann,
    wenn die Schleife noch weiterläuft, denn außerhalb der for Schleife hat i keine Gültigkeit mehr.

    Beispiel:

    int sicher = 0;
    for (int i = 0; i <= 10; i++){
      // mach was
      sicher = i;
    }
    

    Warum gibt es nicht so etwas:

    int sicher = 0;
    for (int i = 0; i <= 10; i++; sicher){
      // mach was 
    }
    

    Also ein FOR Schleifenkonstrukt mit 4 Anweisungen, wobei die letzte dafür steht,
    den Wert der Zählvariable i in die angegebene Variable "sicher" zu sichern, wenn die Schleife an ihrem Ende angekommen ist.

    Dadurch würde man sich das ständige sichern ersparen und man müsste sich so etwas auch nicht mit einer while schleife selber basteln.

    Gibt es irgendeine Programmiersprache, die so ein Feature bietet?



  • Weil es Schwachsinn wäre. Schreib halt sowas:

    int i = 0;
    for (; i <= 10; i++)
    {
    
    }
    


  • Ich glaub ich verstehe das Problem nicht... Deklarier deine Zählvariable doch einfach vor der Schleife, dann ist sie auch danach noch existent/gültig.



  • Mechanics schrieb:

    Weil es Schwachsinn wäre. Schreib halt sowas:

    int i = 0;
    for (; i <= 10; i++)
    {
    
    }
    

    Wusste nicht, dass das geht.

    Aber obiges Bsp. gibt als Ergebnis für i = 11 aus und nicht 10.



  • Aber obiges Bsp. gibt als Ergebnis für i = 11 aus und nicht 10.

    Logischerweise... Was ist denn das eigentliche Problem?
    Sinn macht es erst wenn in der for-Schleife ein break vorkommt und man den letzten Index erhalten will.



  • s/Index/Wert der Zählvariable/

    Ich hatte irgendwie Arrays im Kopf.



  • Ich bin mir ziemlich sicher, dass du dir eine haskell-library schreiben kannst, die genau das macht, nur halt nicht mit exakt der gleichen Syntax.



  • Marthog schrieb:

    Ich bin mir ziemlich sicher, dass du dir eine haskell-library schreiben kannst, die genau das macht, nur halt nicht mit exakt der gleichen Syntax.

    wobei hier anzumerken ist, das es bei Lisp ein explizites loopen gibt, bei Haskell nicht. Man darf sich also im ungünstigsten Fall die komplette Haskell Abstraktion hineinpfeifen, um überhaupt einigermaßen im Pragmatismus zu sein.
    Aber eine Suche nach Haskell + For loop könnte ähnlich dienlich sein (Z.B. Serveranwendungen).
    Eine zweite Sache ist, dass man bei Haskell sog. "Acceleratortechnik" benutzt, die genau dieses gewünschte Mitzählen macht. Das ist zwar nicht (unbedingt) Teil der grundlegenden Dienstfunktionen der Sprache, aber grundlegende wichtige Programmiertechnik/Abstraktionsknowhow.
    (Kann man auch in C nutzen)

    Auf der Hardwareebene gibt es (normalerweise) lediglich ein Herunterzählen eines schon bekannten Wertes. Den braucht man nicht extra zu sichern, außer man wollte testen ob (im Idealfall) Herunterzähler = 0 ist.

    In C kann man sich die gewünschte Funktionalität in den Header schreiben. Etwa mit if...
    Man schreibt dann auch nicht i <= zaehler sondern eher i < zaehler, um ein Fehlverhalten mit dem Datenformat zu verhüten. Das ist aber in der Praxis selbstverständlich, so dass einem C-Profi die Problematik gar nicht explizit bewußt werden muss.

    Apropos Datenformat: Die Problematiken mit dem Zählen und mit Zahlen in der Programmierung haben eher wenig mit der Programmiersprache zu tun. Es wird wohl davon ausgegangen, dass die Schwierigkeiten beim Anwender beim Erlernen der Programmiertechniken verschwinden.
    Aber wenn man z.B. in einem Haskell Interpreter zwei Hexzahlen (Base 16) zusammenzählt, wird eine Dezimalzahl (Base 10) ausgegeben. Und auch wenn Haskell sich mit Datenformaten um Genauigkeit bemüht, Rechnungen mit (langen) Fließkommazahlen werden im Interpreter (wie überall woanders auch) fehlerhaft ausgegeben.
    (-> Haskell == C-Proramm)



  • Mit Hilfsvariable:

    int i = 0;
    int j = i;
    for (; i <= 10; j = i++ );
    cout << j;
    


  • for Schleife erweitern schrieb:

    Mechanics schrieb:

    Weil es Schwachsinn wäre. Schreib halt sowas:

    int i = 0;
    for (; i <= 10; i++)
    {
    
    }
    

    Wusste nicht, dass das geht.

    Aber obiges Bsp. gibt als Ergebnis für i = 11 aus und nicht 10.

    Entferne aus dem i<=10 (im Schleifenkopf) das = 😃



  • EOP schrieb:

    Mit Hilfsvariable:

    int i = 0;
    int j = i;
    for (; i <= 10; j = i++ );
    cout << j;
    

    Wozu das ganze? Die Variable i reicht doch völlig aus?



  • Speicherverbrauchswacht schrieb:

    EOP schrieb:

    Mit Hilfsvariable:

    int i = 0;
    int j = i;
    for (; i <= 10; j = i++ );
    cout << j;
    

    Wozu das ganze? Die Variable i reicht doch völlig aus?

    Klar macht das Ganze nicht viel Sinn. War nur ein POC.



  • wie wäre es mit

    int i;
    
    for(i=0;i<10;i++)
    {
    //inhalt
    }
    
    if(i==10)
    {
    //Array durchgelaufen
    }
    else
    {
    //schleife vorzeitig abgebrochen
    }
    

    dass man seine variablen nicht mitten im programmcode definieren sollte, gilt nicht nur bei c sondern auch bei c++.



  • HansKlaus schrieb:

    dass man seine variablen nicht mitten im programmcode definieren sollte, gilt nicht nur bei c sondern auch bei c++.

    Das ist nicht korrekt. In C++ sollte man Variablen immer möglichst spät deklarieren. Und wenn sie im Programmfluss erst später benötigt werden, dann ist die Deklaration halt mitten im Programmcode.

    Ein kleiner Grund ist die Lesbarkeit. Es hilft zum einen dem Verständnis des Codes, wenn die Deklarationen nahe bei der Verwendung ist.

    Gewichtiger ist, dass in C++ die Deklaration von Variablen unter Umständen einen Konstruktoraufruf erfordert. Und den will man eigentlich gar nicht machen, wenn die Codestelle gar nicht erreicht wird, da entweder mittels return Vorzeitig aus der Funktion raus gesprungen wird oder eine Exception auftritt oder der Codestück einfach in einem if enthalten ist.



  • Ich halte die Lesbarkeit für wesentlich wichtiger als das Vermeiden von Konstruktoraufrufen.
    (Im Allgemeinen. Dass ich das nicht auf wirklich performancekritische Stellen beziehe sollte klar sein.)


Log in to reply