Bitweise Operatoren für Boolesche Operatoren in C++ verwenden

Question

Gibt es einen Grund, die bitweisen Operatoren &, | und ^ für "bool"-Werte in C++ nicht zu verwenden?

Manchmal stoße ich auf Situationen, in denen ich möchte, dass genau eine von zwei Bedingungen wahr ist (XOR), also füge ich einfach den Operator ^ in einen bedingten Ausdruck ein. Manchmal möchte ich auch, dass alle Teile einer Bedingung ausgewertet werden, unabhängig davon, ob das Ergebnis wahr ist oder nicht (anstelle eines Kurzschlusses), daher verwende ich & und |. Manchmal muss ich auch boolesche Werte akkumulieren, wobei &= und |= sehr nützlich sein können.

Ich habe ein paar hochgezogene Augenbrauen bekommen, als ich dies tat, aber der Code ist immer noch sinnvoll und sauberer als er es sonst wäre. Gibt es einen Grund, diese nicht für bools zu verwenden? Gibt es moderne Compiler, die in diesem Fall schlechte Ergebnisse liefern?

Answer 1

|| y && sind boolesche Operatoren, und die eingebauten Operatoren geben garantiert entweder true o false . Sonst nichts.

| , & y ^ sind bitweise Operatoren. Wenn der Bereich der Zahlen, auf denen Sie operieren, nur 1 und 0 ist, dann sind sie genau dasselbe, aber in Fällen, in denen Ihre Booleschen Operatoren nicht strikt 1 und 0 sind - wie es in der Sprache C der Fall ist - können Sie mit einem Verhalten enden, das Sie nicht wollten. Zum Beispiel:

BOOL two = 2;
BOOL one = 1;
BOOL and = two & one;   //and = 0
BOOL cand = two && one; //cand = 1

In C++ hingegen ist die bool Typ ist garantiert nur entweder ein true oder eine false (die sich jeweils implizit in 1 y 0 Die Tatsache, dass die Leute nicht daran gewöhnt sind, solche Dinge im Code zu sehen, ist jedoch ein gutes Argument dafür, es nicht zu tun. Sagen Sie einfach b = b && x und damit fertig sein.

Answer 2

Zwei Hauptgründe. Kurz gesagt, denken Sie sorgfältig darüber nach; es könnte einen guten Grund dafür geben, aber wenn es einen gibt, seien Sie SEHR explizit in Ihren Kommentaren, denn es kann spröde sein und, wie Sie selbst sagen, sind die Leute im Allgemeinen nicht daran gewöhnt, solchen Code zu sehen.

Bitweises xor != Logisches xor (außer für 0 und 1)

Erstens, wenn Sie mit anderen Werten arbeiten als false y true (oder 0 y 1 als ganze Zahlen), die ^ Operator kann ein Verhalten einführen, das einem logischen xor nicht entspricht. Zum Beispiel:

int one = 1;
int two = 2;

// bitwise xor
if (one ^ two)
{
  // executes because expression = 3 and any non-zero integer evaluates to true
}

// logical xor; more correctly would be coded as
//   if (bool(one) != bool(two))
// but spelled out to be explicit in the context of the problem
if ((one && !two) || (!one && two))
{
  // does not execute b/c expression = ((true && false) || (false && true))
  // which evaluates to false
}

Dank an den Benutzer @Patrick, der dies als Erster zum Ausdruck brachte.

Reihenfolge der Maßnahmen

Zweitens, | , & y ^ als bitweise Operatoren keinen Kurzschluss verursachen. Außerdem können mehrere bitweise Operatoren, die in einer einzigen Anweisung aneinandergereiht sind - sogar mit expliziten Klammern - von optimierenden Compilern neu geordnet werden, da alle 3 Operationen normalerweise kommutativ sind. Dies ist wichtig, wenn die Reihenfolge der Operationen von Bedeutung ist.

Mit anderen Worten

bool result = true;
result = result && a() && b();
// will not call a() if result false, will not call b() if result or a() false

führt nicht immer zu demselben Ergebnis (oder Endzustand) wie

bool result = true;
result &= (a() & b());
// a() and b() both will be called, but not necessarily in that order in an
// optimizing compiler

Dies ist besonders wichtig, weil Sie möglicherweise keine Kontrolle über die Methoden a() y b() oder jemand anderes kommt und ändert sie später, ohne die Abhängigkeit zu verstehen, und verursacht einen unangenehmen (und oft nur in der Release-Build-Version auftretenden) Fehler.

Answer 3

Die hochgezogenen Augenbrauen sollten Ihnen genug sagen, um es nicht mehr zu tun. Sie schreiben den Code nicht für den Compiler, Sie schreiben ihn zuerst für Ihre Programmierkollegen und dann für den Compiler. Selbst wenn die Compiler funktionieren, ist es nicht das, was Sie wollen, andere Leute zu überraschen - bitweise Operatoren sind für Bit-Operationen, nicht für Bools.
Ich nehme an, Sie essen Äpfel auch mit einer Gabel? Es funktioniert, aber es überrascht die Leute, also ist es besser, es nicht zu tun.

Answer 4

Ich denke

a != b

ist das, was Sie wollen

Answer 5

Nachteile der Bitlevel-Operatoren.

Sie fragen:

"Gibt es einen Grund, die bitweisen Operatoren nicht zu verwenden? & , | y ^ für "bool"-Werte in C++? "

Ja, die logische Operatoren d.h. die eingebauten booleschen Operatoren auf hoher Ebene ! , && y || bieten die folgenden Vorteile:

• Garantiert Umwandlung von Argumenten a bool d.h. zu 0 y 1 Ordinalwert.

• Garantiert Kurzschlussauswertung wobei die Auswertung des Ausdrucks endet, sobald das Endergebnis bekannt ist.
  Dies kann als eine Baum-Wert-Logik interpretiert werden, mit Wahr , Falsch y Unbestimmt .

• Lesbare textliche Entsprechungen not , and y or auch wenn ich sie nicht selbst verwende.
  Wie der Leser Antimony in einem Kommentar anmerkt, haben auch die Bitlevel-Operatoren alternative Token, nämlich bitand , bitor , xor y compl aber meiner Meinung nach sind diese weniger gut lesbar als and , or y not .

Einfach ausgedrückt, ist jeder dieser Vorteile der Operatoren auf hoher Ebene ein Nachteil der Operatoren auf Bitebene.

Da die bitweisen Operatoren nicht in 0/1 umgewandelt werden können, erhalten Sie z. B. 1 & 2 → 0 , während 1 && 2 → true . Auch ^ , bitweise exklusive oder, kann sich auf diese Weise falsch verhalten. Als boolesche Werte betrachtet sind 1 und 2 dasselbe, nämlich true , aber als Bitmuster sind sie anders.

---

Wie man logisch ausdrückt entweder/oder in C++.

Dann geben Sie ein paar Hintergrundinformationen zur Frage,

"Ich stoße manchmal auf Situationen, in denen ich möchte, dass genau eine von zwei Bedingungen wahr ist (XOR), also füge ich den ^-Operator einfach in einen bedingten Ausdruck ein."

Nun, die bitweisen Operatoren haben höherer Vorrang als die logischen Operatoren. Dies bedeutet insbesondere, dass in einem gemischten Ausdruck wie

a && b ^ c

erhalten Sie das vielleicht unerwartete Ergebnis a && (b ^ c) .

Schreiben Sie stattdessen einfach

(a && b) != c

präziser auszudrücken, was Sie meinen.

Für das Mehrfachargument entweder/oder es gibt keinen C++-Operator, der diese Aufgabe erfüllt. Wenn Sie zum Beispiel schreiben a ^ b ^ c dann ist das kein Ausdruck, der sagt "entweder a , b o c wahr ist". Stattdessen heißt es: "Eine ungerade Anzahl von a , b y c wahr sind", was 1 von ihnen oder alle 3 sein können

Um das allgemeine Entweder-Oder auszudrücken, wenn a , b y c sind vom Typ bool schreiben Sie einfach

(a + b + c) == 1

oder, bei nicht bool Argumente, konvertieren Sie sie in bool :

(!!a + !!b + !!c) == 1

---

Verwendung von &= um boolesche Ergebnisse zu akkumulieren.

Sie führen weiter aus,

"Ich muss auch manchmal boolesche Werte akkumulieren, und &= y |=? kann sehr nützlich sein."

Nun, dies entspricht der Überprüfung, ob jeweils alle o jede Bedingung erfüllt ist, und de-Morgansches Gesetz sagt Ihnen, wie Sie von einem zum anderen kommen. Das heißt, Sie brauchen nur einen von beiden. Sie könnten im Prinzip Folgendes verwenden *= als &&= -Operator (denn wie der gute alte George Boole entdeckte, kann logisches UND sehr leicht als Multiplikation ausgedrückt werden), aber ich denke, dass dies die Betreuer des Codes verwirren und vielleicht in die Irre führen würde.

Beachten Sie auch:

struct Bool
{
    bool    value;

    void operator&=( bool const v ) { value = value && v; }
    operator bool() const { return value; }
};

#include <iostream>

int main()
{
    using namespace std;

    Bool a  = {true};
    a &= true || false;
    a &= 1234;
    cout << boolalpha << a << endl;

    bool b = {true};
    b &= true || false;
    b &= 1234;
    cout << boolalpha << b << endl;
}

Ausgabe mit Visual C++ 11.0 und g++ 4.7.1:

true
false

Der Grund für die unterschiedlichen Ergebnisse ist, dass der Bitlevel &= bietet keine Umwandlung in bool seines Arguments auf der rechten Seite.

Welches dieser Ergebnisse wünschen Sie sich also für Ihre Verwendung von &= ?

Wenn ersteres, true dann definieren Sie besser einen Operator (z. B. wie oben) oder eine benannte Funktion, oder verwenden Sie eine explizite Umwandlung des Ausdrucks auf der rechten Seite, oder schreiben Sie die Aktualisierung vollständig.