3. Division und Rest

Division und Rest


  • Es geht ja primär auch um den Vergleich.
    Im übrigen wenn ich erst in Zweile 18 rechnen lasse, bekomm ich nen Error.
    Könnte am Compiler liegen.

    0 2 Antworten
  • Mod

    @Lou-Cyphr3 sagte in Division und Rest:

    Könnte am Compiler liegen.

    Nein.

    1

  • Weiters ist auch die Bedingung falsch. a % b ist der Rest der bei der Division a / b übrig bleibt, als Ganzzahl. D.h. a % b ist Null wenn die Division ohne Rest möglich ist. Und bei der Konvertierung einer Ganzzahl in einen boolschen Ausdruck wird Null zu false konvertiert und alles andere zu true.

    D.h. a % b, nach bool konvertiert, ist immer dann true wenn die Division nicht ohne Rest möglich ist.

    0

  • @Lou-Cyphr3 sagte in Division und Rest:

    Im übrigen wenn ich erst in Zweile 18 rechnen lasse, bekomm ich nen Error.
    Könnte am Compiler liegen.

    Na dann probier's mal mit Zeile 15. Oder mit C++ Lernen 🙂

    0

  • Okay danke . Ich habs jetzt. Ich bin jetzt den Weg über ungleich true gegangen.

    0

  • Also ich fände ja (a % b) == 0 deutlich besser zu lesen/verstehen. Ganz abgesehen davon dass Vergleiche mit true sowieso ... "gefährlich" sind.

    0

  • @hustbaer sagte in Division und Rest:

    .Ganz abgesehen davon dass Vergleiche mit true sowieso ... "gefährlich" sind.

    Echt? Das überrascht mich jetzt. Kannst du das näher erklären?

    0
    D
     2 Antworten
  • D

    @Lou-Cyphr3

    In C gilt der Wert 0 als falsch, alles andere als wahr. ( also auch 2 oder -12345)

    false ist 0
    !false (not false) also true ist 1

    123 % 10 = 3, also wahr. Aber der Vergleich mit true ist nicht erfolgreich.

    0

  • Ein boolscher Wert ist schon entweder true oder false, d.h. du brauchst nicht mehr zu vergleichen:

    cout << erg_div << endl;
    0

  • @Lou-Cyphr3 sagte in Division und Rest:

    @hustbaer sagte in Division und Rest:

    .Ganz abgesehen davon dass Vergleiche mit true sowieso ... "gefährlich" sind.

    Echt? Das überrascht mich jetzt. Kannst du das näher erklären?

    Man kann bei Refactorings leicht die Konvertierung nach bool übersehen.
    Beispiel:

    bool foo = a % b;
if (foo != true) {
    // ...
}

    Refactoring: "unnötige" Variable entfernen. Ergebnis:

    if ((a % b) != true) {
    // ...
}

    Und schwupps haben wir ein gänzlich anderes Verhalten.
    Im neuen Code wird jetzt true in einen Integer-Typ mit Wert 1 konvertiert, und dann mit dem Ergebnis von a % b verglichen.
    Im alten Code ist die Bedingung wahr wenn a % b gleich 0 ist. Im neuen Code ist die Bedingung wahr wenn a % b ungleich 1 ist.

    Weiters gibt es etliche APIs die einen wahr/falsch Wert als Integer zurückgeben - die WinAPI ist z.B. voll davon. Auch hier gilt dass 0 für false steht und alles andere für true. Und auch hier ist nicht sicher dass "alles andere" immer nur 1 ist - es kann irgend ein Wert ausser 0 sein.

    => Mit true vergleichen ist potentiell gefährlich.

    Weiters ist es auch unnötig. Statt if (x == true) kann man genau so gut if (x) schreiben und statt if (x != true) kann man if (!x) schreiben.
    (Vorausgesetzt x ist ein Ausdruck dessen Wert vom Typ bool ist. Wenn der Typ nicht bool ist macht es natürlich einen Unterschied - genau darum geht's ja.)

    Vergleiche mit false sind weniger problematisch, aber genau so unnötig.

    1
    W
     1 Antwort
  • W

    Wenn man Spaß daran hat, kann man das sogar weiter treiben (schon so ähnlich im Code gesehen):

    bool x;
if (functionReturningBool() == true) x = true; else x = false;
bool y = x ? true : false;
if (y == true) { ... }
    0

  • @hustbaer
    Danke für die Ausführung.
    Ich bin nur verwirrt weil ich heute explizit meinen Lehrer danach gefragt habe
    und er nochmals für true und false plädiert hat.
    Ich frage mich gerade wann überhaupt bool einsetzten?

    0 2 Antworten
  • Mod

    @Lou-Cyphr3 sagte in Division und Rest:

    Ich frage mich gerade wann überhaupt bool einsetzten?

    @hustbaer hat ja nicht gesagt, nie bool zu benutzen, sondern die Form des Vergleichs zu vermeiden, die du benutzt hast. Das ist ein ganz großer Unterschied.

    Ich zitiere mich mal aus einem anderen Thread von heute: Ein Programm sollte sich wie ein Text lesen lassen.

    Welcher Text klingt besser?
    "Das Ergebnis ist wahr"
    "Das Ergebnis ist gleich der Wahrheit"

    Generell ist bool aber offensichtlicherweise für die Dinge gut, für die es gemacht ist. Also Dinge, die wahr oder falsch sein können. Als Ergebnis einer Rechenoperation ist das ein ungewöhnlicher Einsatz. Das Ergebnis einer Rechenoperation ist in diesem Fall eine Ganzzahl und du möchtest wissen, ob diese ungleich 0 ist. Dann schreib das doch auch so! Die bool-Trickserei mag letztendlich zwar das gleiche erreichen, aber nur über komische Konvertierungen und es drückt dabei nicht deine Absichten aus. Im Maschinencode schreibt der Compiler am Ende sowieso immer den gleichen Code, aber nur wenn du deine Absichten klar ausdrückst, stellst du sicher, dass andere Menschen deinen Code gut verstehen können, und das dein Code robust gegen unerwartete Änderungen ist. Je klarer du dich ausdrückst, desto besser funktioniert das.

    1

  • @Lou-Cyphr3
    Wie @SeppJ schon geschrieben hat: bool, true und false sind alle voll OK und ich verwende sie alle. Z.B. bool Parameter/Variablen mit 1 statt true zu befüllen wäre hochgradig bekloppt. Was ich nur nicht mache ist mit true oder false zu vergleichen.
    Und was ich auch nicht mache ist sowas wie...

    bool var = a % b;

    ...also implizite Konvertierung von einem Integer-Typ nach bool.
    (Ausgenommen in bestimmten Fällen in if Statements - aber das zu erklären würde jetzt zu weit gehen.)

    Unsere Compiler sind soger so eingestellt dass sie bei bool var = a % b; ne Warning werfen, und da wir mit "treat warnings as errors" bauen... 😉

    0
Anmelden zum Antworten