Gibt es einen technischen Grund, > (

Lesezeit: 7 Minuten

Benutzeravatar von Zingam
Zingam

Ich sehe fast nie einen for Schleife so:

for (int i = 0; 5 != i; ++i)
{}

Gibt es einen technischen Grund für die Verwendung? > oder < Anstatt von != beim Erhöhen um 1 in a for Schleife? Oder ist das eher eine Konvention?

  • Es macht es lesbarer, plus, wenn Sie sich jemals ändern i++ zu i+=2 (zum Beispiel) läuft es sehr lange (oder möglicherweise für immer). Nun, da Sie normalerweise verwenden < für die Fälle, in denen Sie den Iterator um erhöhen mehr als 1, können Sie genauso gut verwenden < auch für den Fall, dass Sie es um 1 erhöhen (für Konsistenz).

    – barak manos

    16. Juli 2015 um 13:31 Uhr


  • 5 != i ist böse

    – Slava

    16. Juli 2015 um 13:32 Uhr

  • Du solltest dir immer bewusst sein, was du tust, aber Fehler wirst du trotzdem machen. Die Verwendung von < verringert die Möglichkeit, dass jemand einen Fehler in diesen Code einfügt.

    – Aurast

    16. Juli 2015 um 15:53 ​​Uhr


  • @OleTange Wenn Sie mit Gleitkommazahlen iterieren, sind Sie bereits am Arsch.

    – CaptainCodeman

    16. Juli 2015 um 16:27 Uhr

  • @Slava … nicht böse. Sie wurden anscheinend noch nie in C von einem einfachen Tippfehler gebissen, der den Unterschied zwischen macht if ( i == 5 ) ... und if ( i = 5 ). Sehr unterschiedliche Dinge. Das Umkehren der Operanden verhindert das Problem: da Literale keine sind lvals, sie können nicht zugewiesen werden und der Compiler schleudert auf den Tippfehler. @Zingam: gute defensive Programmierung!

    – Nicolas Carey

    16. Juli 2015 um 17:38 Uhr

Benutzeravatar von Antonio
Antonio

while (time != 6:30pm) {
    Work();
}

Es ist 18:31 Uhr… Verdammt, meine nächste Chance, nach Hause zu gehen, ist morgen! 🙂

Dies soll zeigen, dass die stärkere Einschränkung Risiken mindert und wahrscheinlich intuitiver zu verstehen ist.

  • Manchmal endet der Versuch, “Risiken zu mindern”, nur damit, den Fehler zu verbergen. Wenn die Gestaltung der Schleife verhindern soll, dass die 18:30 Uhr unbemerkt vorbeirutscht, dann verwenden < wird den Fehler verbergen, aber mit != würde es offensichtlich machen, dass es ein Problem gibt.

    – Adrian McCarthy

    16. Juli 2015 um 17:09 Uhr

  • @AdrianMcCarthy: Nicht unbedingt; Es könnte nur einen zweiten Fehler einführen und eine Diagnose stellen Schwerer.

    – Leichtigkeitsrennen im Orbit

    16. Juli 2015 um 17:20 Uhr

  • @AdrianMcCarthy: Das ist irgendwie mein Punkt; Sie könnten ein paar Instanzen davon haben, die Sie noch nicht gesehen haben;)

    – Leichtigkeitsrennen im Orbit

    16. Juli 2015 um 17:29 Uhr

  • Iteratoren sind meiner Meinung nach ein perfektes Beispiel für den @AdrianMcCarthy-Punkt. Der empfohlene Vergleich für sie ist != anstelle von <.

    – Taekahn

    17. Juli 2015 um 3:45 Uhr

  • Ich habe genau diesen Fehler gesehen (und er hat 3 Monate Debugging verursacht) – aber diese Antwort verfehlt den Punkt völlig. In dem angegebenen Beispiel ist es unmöglich damit die Endbedingung verfehlt wird. Man könnte sogar sagen, dass die bewusste Wahl von != gegenüber < eine starke Behauptung dieser Tatsache darstellt. Ein Risiko zu mindern, das definitiv nicht existiert, ist für mich ein Code-Geruch. (Trotzdem können Sie genauso argumentieren, dass < idiomatisch ist, dass dies ein ebenso guter Grund ist, es zu verwenden wie jeder andere.)

    – Ian Goldby

    20. Juli 2015 um 10:09 Uhr

Elys Benutzeravatar
Ely

Es gibt keinen technischen Grund. Aber es gibt Risikominderung, Wartbarkeit und ein besseres Verständnis des Codes.

< oder > sind stärkere Einschränkungen als != und erfüllen in den meisten Fällen (ich würde sogar sagen in allen praktischen Fällen) genau den gleichen Zweck.

Hier gibt es eine doppelte Frage; und eine interessante Antwort.

  • Es gibt einige Typen, wie z. B. Iteratoren, die < oder > nicht unterstützen, aber == und != unterstützen.

    – Simon B

    16. Juli 2015 um 21:15 Uhr

  • Es ist eine for-Schleife mit int. Keine Iteratoren.

    – Eli

    17. Juli 2015 um 9:36 Uhr

  • “Aber es gibt Risikominderung, Wartbarkeit und ein besseres Verständnis des Codes.” All das sind eigentlich technische Gründe. 🙂

    – TJ Crowder

    18. Juli 2015 um 9:49 Uhr

  • @TJCrowder Was für ein Grund ist es, wenn Sie nur darüber sprechen wollen, was die Maschinen als Ergebnis tun werden?

    – Brillant

    20. Juli 2015 um 21:43 Uhr


  • @DanSheppard Ich würde die Risikominderung und Wartbarkeit im Allgemeinen als geschäftliche Gründe und ein besseres Verständnis des Codes als einen sozialen Grund betrachten (obwohl diese Gründe in diesem Fall alle auf eine technische Angelegenheit angewendet werden). Überlegungen zur “Risikominderung” sind keineswegs auf technische Angelegenheiten beschränkt, und Überlegungen zum “besseren Verständnis des Codes” können sich ändern, wenn Sie mit einer anderen Gruppe von Personen arbeiten (selbst wenn sich die beteiligten Computer überhaupt nicht ändern ).

    – Brillant

    21. Juli 2015 um 16:54 Uhr

Benutzeravatar von 463035818_is_not_a_number
463035818_ist_keine_Nummer

Ja, es gibt einen Grund. Wenn Sie eine (einfache alte Index-basierte) for-Schleife wie diese schreiben

for (int i = a; i < b; ++i){}

dann funktioniert es wie erwartet für alle Werte von a und b (dh null Iterationen, wenn a > b anstelle von unendlich, wenn Sie verwendet hätten i == b;).

Andererseits würden Sie für Iteratoren schreiben

for (auto it = begin; it != end; ++it) 

weil jeder Iterator eine implementieren sollte operator!=aber nicht für jeden Iterator ist es möglich, eine bereitzustellen operator<.

Auch bereichsbasierte for-Schleifen

for (auto e : v)

sind nicht nur ausgefallener Zucker, sondern reduzieren messbar die Wahrscheinlichkeit, falschen Code zu schreiben.

  • Schönes Beispiel. Ich hätte Interesse an einem Fall für != Anstatt von <. Ich persönlich habe das nie benutzt, denke ich.

    – Eli

    16. Juli 2015 um 14:05 Uhr

  • Die gleiche Schleife mit != statt < macht deutlich, was der Vorteil von < (oder >) in diesem Zusammenhang ist. for (int i=a; i != b; i++) {}

    – Paul Smith

    16. Juli 2015 um 15:01 Uhr


  • Alles andere verwenden != mit Iteratoren ist ziemlich gefährlich, weil manchmal Die Iteratoren können kleiner als verglichen werden (es ist zum Beispiel ein Zeiger), aber der Vergleich ist bedeutungslos (es ist eine verknüpfte Liste).

    – Zan Luchs

    16. Juli 2015 um 22:21 Uhr

  • Lernen Sie ernsthaft, Leerzeichen zu verwenden.

    – Meilen Route

    21. Juli 2015 um 5:20 Uhr

  • for (int i=a;i<b;i++){} vs. for (int i = a; i < b; i++);

    – Meilen Route

    22. Juli 2015 um 4:44 Uhr

Benutzeravatar von johan d
Johann D

Sie können so etwas haben

for(int i = 0; i<5; ++i){
    ...
    if(...) i++;
    ...
}

Wenn Ihre Schleifenvariable vom inneren Code geschrieben wird, wird die i!=5 könnte diese Schleife nicht durchbrechen. Dies ist sicherer, um auf Ungleichheit zu prüfen.

Bearbeiten über Lesbarkeit. Viel häufiger wird die Ungleichheitsform verwendet. Daher ist dies sehr schnell zu lesen, da es nichts Besonderes zu verstehen gibt (die Gehirnbelastung wird reduziert, da die Aufgabe häufig ist). Es ist also cool für die Leser, sich diese Gewohnheiten zunutze zu machen.

Benutzeravatar von Paul Ogilvie
Paul Ogilvie

Und nicht zuletzt heißt das defensive Programmierungwas bedeutet, immer den stärksten Fall zu nehmen, um aktuelle und zukünftige Fehler zu vermeiden, die das Programm beeinflussen.

Der einzige Fall, in dem eine defensive Programmierung nicht erforderlich ist, ist dort, wo Zustände durch Vor- und Nachbedingungen bewiesen wurden (aber dann ist der Beweis die defensivste aller Programmierungen).

  • Ein gutes Beispiel dafür: Speicher ist anfällig für Bit-Flips (SEUs) durch Strahlung verursacht. Bei Verwendung eines int für ein i != 15 Bedingung läuft der Zähler lange, wenn irgendetwas über dem vierten Bit umgedreht wird, besonders auf Maschinen, wo sizeof(int) beträgt 64. SEUs sind in größerer Höhe oder im Weltraum (wegen der höheren Strahlung) oder in großen Supercomputern (weil so viel Speicher vorhanden ist) ein sehr reales Problem.

    – Josh Sanford

    20. September 2016 um 13:56 Uhr

  • Zu denken, dass Ihr Programm gut läuft, wenn Strahlung Ihr Gedächtnis verändert, ist eine optimistische und antikatastrophale Denkweise … guter Kommentar! 🙂

    – Luis Colorado

    5. Oktober 2016 um 5:47 Uhr

Benutzeravatar von Nicholas Carey
Nicolas Carey

Ich würde argumentieren, dass ein Ausdruck wie

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

ist mehr Ausdruck der Absicht als ist

for ( int i = 0 ; i != 100 ; ++i )
{
  ...
}

Ersteres weist eindeutig darauf hin, dass die Bedingung ein Test für eine exklusive Obergrenze einer Spanne ist; Letzteres ist ein binärer Test einer Austrittsbedingung. Und wenn der Körper der Schleife nicht trivial ist, ist es möglicherweise nicht ersichtlich, dass der Index nur in geändert wird for Aussage selbst.

  • Ein gutes Beispiel dafür: Speicher ist anfällig für Bit-Flips (SEUs) durch Strahlung verursacht. Bei Verwendung eines int für ein i != 15 Bedingung läuft der Zähler lange, wenn irgendetwas über dem vierten Bit umgedreht wird, besonders auf Maschinen, wo sizeof(int) beträgt 64. SEUs sind in größerer Höhe oder im Weltraum (wegen der höheren Strahlung) oder in großen Supercomputern (weil so viel Speicher vorhanden ist) ein sehr reales Problem.

    – Josh Sanford

    20. September 2016 um 13:56 Uhr

  • Zu denken, dass Ihr Programm gut läuft, wenn Strahlung Ihr Gedächtnis verändert, ist eine optimistische und antikatastrophale Denkweise … guter Kommentar! 🙂

    – Luis Colorado

    5. Oktober 2016 um 5:47 Uhr

Benutzeravatar von Escualo
Escualo

Iteratoren sind ein wichtiger Fall, wenn Sie die am häufigsten verwenden != Notation:

for(auto it = vector.begin(); it != vector.end(); ++it) {
 // do stuff
}

Zugegeben: in der Praxis würde ich das gleiche schreiben unter Berufung auf a range-for:

for(auto & item : vector) {
 // do stuff
}

aber der Punkt bleibt: Normalerweise vergleicht man Iteratoren mit == oder !=.

  • Iteratoren haben oft nur eine Vorstellung von Gleichheit / Ungleichheit und keine Ordnung, deshalb verwendet man != für Sie. Zum Beispiel in einem std::vector Sie könnte verwenden < da der Iterator an den Index / Pointer gebunden ist, aber in a std::set Es gibt keine so strenge Reihenfolge, da es sich um einen binären Baum handelt.

    –Martin C.

    16. Juli 2015 um 20:38 Uhr


1425760cookie-checkGibt es einen technischen Grund, > (

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy