mit bool rechnen - Schlechtes Design?

Nexus

Ja, das Beispiel ist standardkonform, da true in arithmetischen Ausdrücken als 1 und false als 0 (beide vom Typ int ) interpretiert werden.

Guter Stil ist es nicht, es macht nämlich keinen Sinn. Wenn man rechnet, kann man Zahlen nehmen. Allerdings lassen sich gewisse Ausdrücke mit bool -Rechnereien kompakter schreiben, weil man z.B. ohne if auskommt. Das sind dann aber komplexere Ausdrücke vom Typ bool (oft Ergebnisse von logischen oder relationalen Operatoren) und keine Literale.

Ob das dann guter Stil ist, sieht jeder ein wenig anders. Ich selbst habe grundsätzlich nichts dagegen, sofern man es halbwegs entziffern kann oder ein vernünftiger Kommentar da steht.

Ich denke, das fällt unter "integral promotion". Bevor + ausgerechnet wird, werden die boolschen Ausdrücke erst zu int-Werten konvertiert. Demnach liefert der Ausdruck false-true den Wert -1 und ist vom Typ int.

Das ganze frage ich deshalb: Ich habe eine Klasse die eine Membervariable m_state und eine Vergleichsfunktion compare() enthält. Die Vergleichsfunktion funktioniert dann so:

int MyClass::compare(const MyClass& rhs) const {
    return m_state - rhs.m_state;
}

freaky

Komisches compare

FreakY<3Cpp schrieb:

Komisches compare

Ist ja nur ein Teil - natürlich wird noch nach anderen Kriterien verglichen...
Oder meinst du etwas anderes?

volkard

FreakY<3Cpp schrieb:

Komisches compare

Ganz normales Compare. Dreiwertige Rückgabe mitr <0, ==0, >0 ist nicht so unüblich. Siehe strcmp. Ein wenig weiter weg von der STL, aber C ist ja auch was Schönes.

daersc schrieb:

Ist ja nur ein Teil - natürlich wird noch nach anderen Kriterien verglichen...

Das macht mir jetzt ein wenig Angst.

volkard schrieb:

daersc schrieb:

Ist ja nur ein Teil - natürlich wird noch nach anderen Kriterien verglichen...

Das macht mir jetzt ein wenig Angst.

Es ist so, dass zuerst nach dem "vorrangigen" Kriterium verglichen wird. Wenn eine Unterscheidung bereits möglich ist, ist das der Rückgabewert. Wenn nicht, wird das nächste Kriterium herangezogen. Wenn alle Vergleiche kein Ergebnis bringen, liefert die Funktion 0 zurück.

volkard schrieb:

Ein wenig weiter weg von der STL, aber C ist ja auch was Schönes.

Ist das nicht sinnvoll, das die < und == Operatoren nur noch diese Funktion aufrufen müssen? (Die übrigen werden von Boost.Operators erstellt...
Im Übrigen: http://www.cplusplus.com/reference/string/string/compare/ Weit weg von der STL???

volkard

Wie ist das mit der Geschwindigkeit, wenn Du den kleinen op< implementierst, indem du die große compare verwendest?
Sinnvoll ist es wohl, wenn es leicht zu lesen ist und keine Zusatzkosten gegenüber asm hat. Vermutlich solltest Du die ops < und == explizit selber bauen und die anderen kannst Du ja gerne boosteln lassen. DIe beiden erst zusammenzufassen, um sie dann wieder mit if auseinanderzuklamüsern, riecht nach Java, UML, Struktogrammen, Refactoring-Menus und so.

freaky

volkard schrieb:

Ganz normales Compare.

Das natürlich, das Compare von .NET macht das gleiche, aber nicht mit bool, sondern das gibt dann jenachdem -1, 0 oder 1 zurück.

Shade Of Mine

FreakY<3Cpp schrieb:

volkard schrieb:

Ganz normales Compare.

Das natürlich, das Compare von .NET macht das gleiche, aber nicht mit bool, sondern das gibt dann jenachdem -1, 0 oder 1 zurück.

Tut dieses Compare hier ja auch.
Ich sehe hier nichts komisches, alles vollkommen normal.

freaky

Naja für mich ist es nunmal unüblich mit bool zu rechnen, auch wenn es geht

Shade Of Mine

FreakY<3Cpp schrieb:

Naja für mich ist es nunmal unüblich mit bool zu rechnen, auch wenn es geht

ist fuer dich dann auch ein

int strcmp(char const* a, char const* b) {
  while(*a && *a++==*b++)
    ;
  return *a-*b;
}

komisch?

Ich wuerde halt ein:

if(a<b) return -1;
else if(a==b) return 0;
else return 1;

komisch finden

freaky

Ja finde ich persönlich nicht gerade ansprechend, aber bei solch einem Thema vertritt nunmal jeder seine eigene Ansicht.

volkard schrieb:

Vermutlich solltest Du die ops < und == explizit selber bauen und die anderen kannst Du ja gerne boosteln lassen. DIe beiden erst zusammenzufassen, um sie dann wieder mit if auseinanderzuklamüsern, riecht nach Java, UML, Struktogrammen, Refactoring-Menus und so.

Sobald die Objekte nicht gleich sind, bricht die Funktion in jedem Fall ab...
Und was ist mit der Vermeidung der Codeduplizierung? Immerhin sehen beide Op's fast gleich aus...