So verbessern Sie die Logik, um zu überprüfen, ob 4 boolesche Werte in einigen Fällen übereinstimmen

Ich habe vier boolWerte:

bool bValue1;
bool bValue2;
bool bValue3;
bool bValue4;

Die akzeptablen Werte sind:

         Scenario 1 | Scenario 2 | Scenario 3
bValue1: true       | true       | true
bValue2: true       | true       | false
bValue3: true       | true       | false
bValue4: true       | false      | false

So ist dieses Szenario beispielsweise nicht akzeptabel:

bValue1: false
bValue2: true
bValue3: true
bValue4: true

Im Moment habe ich mir diese ifAussage ausgedacht, um schlechte Szenarien zu erkennen:

if(((bValue4 && (!bValue3 || !bValue2 || !bValue1)) ||
   ((bValue3 && (!bValue2 || !bValue1)) ||
   (bValue2 && !bValue1) ||
   (!bValue1 && !bValue2 && !bValue3 && !bValue4))
{
    // There is some error
}

Kann diese Anweisungslogik verbessert / vereinfacht werden?

Ich würde die Lesbarkeit anstreben: Sie haben nur 3 Szenarien, behandeln Sie sie mit 3 separaten ifs:

bool valid = false;
if (bValue1 && bValue2 && bValue3 && bValue4)
    valid = true; //scenario 1
else if (bValue1 && bValue2 && bValue3 && !bValue4)
    valid = true; //scenario 2
else if (bValue1 && !bValue2 && !bValue3 && !bValue4)
    valid = true; //scenario 3

Einfach zu lesen und zu debuggen, IMHO. Sie können auch eine Variable zuweisen, whichScenariowährend Sie mit dem fortfahren if.

Mit nur 3 Szenarien würde ich mich nicht für etwas entscheiden wie "Wenn die ersten 3 Werte wahr sind, kann ich es vermeiden, den vierten Wert zu überprüfen": Es wird Ihren Code schwieriger zu lesen und zu warten machen.

Keine elegante Lösung vielleicht sicherlich, aber in diesem Fall ist ok: einfach und lesbar.

Wenn Ihre Logik komplizierter wird, werfen Sie diesen Code weg und überlegen Sie, etwas mehr zu verwenden, um verschiedene verfügbare Szenarien zu speichern (wie Zladeck vorschlägt).

Ich mag den ersten Vorschlag in dieser Antwort sehr : einfach zu lesen, nicht fehleranfällig, wartbar

(Fast) off Topic:

Ich schreibe hier bei StackOverflow nicht viele Antworten. Es ist wirklich lustig, dass die oben akzeptierte Antwort bei weitem die am meisten geschätzte Antwort in meiner Geschichte ist (hatte nie mehr als 5-10 Upvotes, bevor ich denke), während sie eigentlich nicht das ist, was ich normalerweise für den "richtigen" Weg halte.

Aber Einfachheit ist oft "der richtige Weg", viele Leute scheinen das zu denken und ich sollte es mehr denken als ich :)

Ich würde auf Einfachheit und Lesbarkeit abzielen.

bool scenario1 = bValue1 && bValue2 && bValue3 && bValue4;
bool scenario2 = bValue1 && bValue2 && bValue3 && !bValue4;
bool scenario3 = bValue1 && !bValue2 && !bValue3 && !bValue4;

if (scenario1 || scenario2 || scenario3) {
    // Do whatever.
}

Stellen Sie sicher, dass Sie die Namen der Szenarien sowie die Namen der Flags durch etwas Beschreibendes ersetzen. Wenn es für Ihr spezifisches Problem sinnvoll ist, können Sie diese Alternative in Betracht ziehen:

bool scenario1or2 = bValue1 && bValue2 && bValue3;
bool scenario3 = bValue1 && !bValue2 && !bValue3 && !bValue4;

if (scenario1or2 || scenario3) {
    // Do whatever.
}

Was hier wichtig ist, ist keine Prädikatenlogik. Es beschreibt Ihre Domain und drückt Ihre Absicht klar aus. Der Schlüssel hier ist, allen Eingaben und Zwischenvariablen gute Namen zu geben. Wenn Sie keine guten Variablennamen finden, kann dies ein Zeichen dafür sein, dass Sie das Problem falsch beschreiben.

Wir können eine Karnaugh-Karte verwenden und Ihre Szenarien auf eine logische Gleichung reduzieren. Ich habe den Online Karnaugh Map Solver mit Schaltung für 4 Variablen verwendet.

Dies ergibt:

Ändern A, B, C, Dzu bValue1, bValue2, bValue3, bValue4, dies ist nichts anderes als:

bValue1 && bValue2 && bValue3 || bValue1 && !bValue2 && !bValue3 && !bValue4

So wird Ihre ifAussage:

if(!(bValue1 && bValue2 && bValue3 || bValue1 && !bValue2 && !bValue3 && !bValue4))
{
    // There is some error
}

• Karnaugh-Karten sind besonders nützlich, wenn Sie viele Variablen und viele Bedingungen haben, die ausgewertet werden sollten true.
• Nachdem Sie die trueSzenarien auf eine logische Gleichung reduziert haben , empfiehlt es sich, relevante Kommentare hinzuzufügen, die die trueSzenarien angeben .

Die eigentliche Frage hier ist: Was passiert, wenn ein anderer Entwickler (oder sogar Autor) diesen Code einige Monate später ändern muss?

Ich würde vorschlagen, dies als Bit-Flags zu modellieren:

const int SCENARIO_1 = 0x0F; // 0b1111 if using c++14
const int SCENARIO_2 = 0x0E; // 0b1110
const int SCENARIO_3 = 0x08; // 0b1000

bool bValue1 = true;
bool bValue2 = false;
bool bValue3 = false;
bool bValue4 = false;

// boolean -> int conversion is covered by standard and produces 0/1
int scenario = bValue1 << 3 | bValue2 << 2 | bValue3 << 1 | bValue4;
bool match = scenario == SCENARIO_1 || scenario == SCENARIO_2 || scenario == SCENARIO_3;
std::cout << (match ? "ok" : "error");

Wenn es viel mehr Szenarien oder mehr Flags gibt, ist ein Tabellenansatz lesbarer und erweiterbarer als die Verwendung von Flags. Für die Unterstützung eines neuen Szenarios ist nur eine weitere Zeile in der Tabelle erforderlich.

int scenarios[3][4] = {
    {true, true, true, true},
    {true, true, true, false},
    {true, false, false, false},
};

int main()
{
  bool bValue1 = true;
  bool bValue2 = false;
  bool bValue3 = true;
  bool bValue4 = true;
  bool match = false;

  // depending on compiler, prefer std::size()/_countof instead of magic value of 4
  for (int i = 0; i < 4 && !match; ++i) {
    auto current = scenarios[i];
    match = bValue1 == current[0] && 
            bValue2 == current[1] && 
            bValue3 == current[2] && 
            bValue4 == current[3];
  }

  std::cout << (match ? "ok" : "error");
}

Meine vorherige Antwort ist bereits die akzeptierte Antwort. Ich füge hier etwas hinzu, das meiner Meinung nach sowohl lesbar als auch einfach und in diesem Fall offen für zukünftige Änderungen ist:

Beginnend mit der Antwort von @ZdeslavVojkovic (die ich ziemlich gut finde), kam ich auf Folgendes:

#include <iostream>
#include <set>

//using namespace std;

int GetScenarioInt(bool bValue1, bool bValue2, bool bValue3, bool bValue4)
{
    return bValue1 << 3 | bValue2 << 2 | bValue3 << 1 | bValue4;
}
bool IsValidScenario(bool bValue1, bool bValue2, bool bValue3, bool bValue4)
{
    std::set<int> validScenarios;
    validScenarios.insert(GetScenarioInt(true, true, true, true));
    validScenarios.insert(GetScenarioInt(true, true, true, false));
    validScenarios.insert(GetScenarioInt(true, false, false, false));

    int currentScenario = GetScenarioInt(bValue1, bValue2, bValue3, bValue4);

    return validScenarios.find(currentScenario) != validScenarios.end();
}

int main()
{
    std::cout << IsValidScenario(true, true, true, false) << "\n"; // expected = true;
    std::cout << IsValidScenario(true, true, false, false) << "\n"; // expected = false;

    return 0;
}

Sehen Sie es bei der Arbeit hier

Nun, das ist die "elegante und wartbare" (IMHO) Lösung, die ich normalerweise anstrebe, aber für den OP-Fall passt meine vorherige "Bündel von Wenns" -Antwort besser zu den OP-Anforderungen, auch wenn sie weder elegant noch wartbar ist.

Ich möchte auch einen anderen Ansatz einreichen.

Meine Idee ist es, die Bools in eine Ganzzahl umzuwandeln und dann mit verschiedenen Vorlagen zu vergleichen:

unsigned bitmap_from_bools(bool b) {
    return b;
}
template<typename... args>
unsigned bitmap_from_bools(bool b, args... pack) {
    return (bitmap_from_bools(b) << sizeof...(pack)) | bitmap_from_bools(pack...);
}

int main() {
    bool bValue1;
    bool bValue2;
    bool bValue3;
    bool bValue4;

    unsigned summary = bitmap_from_bools(bValue1, bValue2, bValue3, bValue4);

    if (summary != 0b1111u && summary != 0b1110u && summary != 0b1000u) {
        //bad scenario
    }
}

Beachten Sie, wie dieses System bis zu 32 Bools als Eingabe unterstützen kann. Das Ersetzen unsigneddurch unsigned long long(oder uint64_t) erhöht die Unterstützung auf 64 Fälle. Wenn Ihnen das nicht gefällt if (summary != 0b1111u && summary != 0b1110u && summary != 0b1000u), können Sie auch eine andere variable Vorlagenmethode verwenden:

bool equals_any(unsigned target, unsigned compare) {
    return target == compare;
}
template<typename... args>
bool equals_any(unsigned target, unsigned compare, args... compare_pack) {
    return equals_any(target, compare) ? true : equals_any(target, compare_pack...);
}

int main() {
    bool bValue1;
    bool bValue2;
    bool bValue3;
    bool bValue4;

    unsigned summary = bitmap_from_bools(bValue1, bValue2, bValue3, bValue4);

    if (!equals_any(summary, 0b1111u, 0b1110u, 0b1000u)) {
        //bad scenario
    }
}

Hier ist eine vereinfachte Version:

if (bValue1 && (bValue2 == bValue3) && (bValue2 || !bValue4)) {
    // acceptable
} else {
    // not acceptable
}

Beachten Sie natürlich, dass diese Lösung stärker verschleiert ist als die ursprüngliche. Ihre Bedeutung ist möglicherweise schwerer zu verstehen.

Update: MSalters in den Kommentaren fanden einen noch einfacheren Ausdruck:

if (bValue1&&(bValue2==bValue3)&&(bValue2>=bValue4)) ...

Überlegen Sie, Ihre Tabellen so direkt wie möglich in Ihr Programm zu übersetzen. Fahren Sie das Programm von der Tabelle aus, anstatt es mit Logik nachzuahmen.

template<class T0>
auto is_any_of( T0 const& t0, std::initializer_list<T0> il ) {
  for (auto&& x:il)
    if (x==t0) return true;
  return false;
}

jetzt

if (is_any_of(
  std::make_tuple(bValue1, bValue2, bValue3, bValue4),
  {
    {true, true, true, true},
    {true, true, true, false},
    {true, false, false, false}
  }
))

Dadurch wird Ihre Wahrheitstabelle direkt wie möglich in den Compiler codiert.

Live-Beispiel .

Sie können auch std::any_ofdirekt verwenden:

using entry = std::array<bool, 4>;
constexpr entry acceptable[] = 
  {
    {true, true, true, true},
    {true, true, true, false},
    {true, false, false, false}
  };
if (std::any_of( begin(acceptable), end(acceptable), [&](auto&&x){
  return entry{bValue1, bValue2, bValue3, bValue4} == x;
}) {
}

Der Compiler kann den Code einbinden, jede Iteration eliminieren und eine eigene Logik für Sie erstellen. In der Zwischenzeit spiegelt Ihr Code genau wider, wie Sie das Problem erkannt haben.

Ich gebe hier nur meine Antwort, wie in den Kommentaren, die jemand vorgeschlagen hat, um meine Lösung zu zeigen. Ich möchte allen für ihre Erkenntnisse danken.

Am Ende habe ich mich entschieden, drei neue "Szenario" boolean-Methoden hinzuzufügen :

bool CChristianLifeMinistryValidationDlg::IsFirstWeekStudentItems(CChristianLifeMinistryEntry *pEntry)
{
    return (INCLUDE_ITEM1(pEntry) && 
           !INCLUDE_ITEM2(pEntry) && 
           !INCLUDE_ITEM3(pEntry) && 
           !INCLUDE_ITEM4(pEntry));
}

bool CChristianLifeMinistryValidationDlg::IsSecondWeekStudentItems(CChristianLifeMinistryEntry *pEntry)
{
    return (INCLUDE_ITEM1(pEntry) &&
            INCLUDE_ITEM2(pEntry) &&
            INCLUDE_ITEM3(pEntry) &&
            INCLUDE_ITEM4(pEntry));
}

bool CChristianLifeMinistryValidationDlg::IsOtherWeekStudentItems(CChristianLifeMinistryEntry *pEntry)
{
    return (INCLUDE_ITEM1(pEntry) && 
            INCLUDE_ITEM2(pEntry) && 
            INCLUDE_ITEM3(pEntry) && 
           !INCLUDE_ITEM4(pEntry));
}

Dann konnte ich meine Validierungsroutine folgendermaßen anwenden:

if (!IsFirstWeekStudentItems(pEntry) && !IsSecondWeekStudentItems(pEntry) && !IsOtherWeekStudentItems(pEntry))
{
    ; Error
}

In meiner Live-Anwendung werden die 4 Bool-Werte tatsächlich aus einem extrahiert, in DWORDdem 4 Werte codiert sind.

Nochmals vielen Dank an alle.

Ich sehe keine Antworten, um die Szenarien zu benennen, obwohl die Lösung des OP genau das tut.

Für mich ist es am besten, den Kommentar jedes Szenarios entweder in einen Variablennamen oder einen Funktionsnamen zu kapseln. Es ist wahrscheinlicher, dass Sie einen Kommentar als einen Namen ignorieren. Wenn sich Ihre Logik in Zukunft ändert, ändern Sie eher einen Namen als einen Kommentar. Sie können einen Kommentar nicht umgestalten.

Wenn Sie diese Szenarien außerhalb Ihrer Funktion wiederverwenden möchten (oder möchten), erstellen Sie eine Funktion, die angibt, was ausgewertet wird ( constexpr/ noexceptoptional, aber empfohlen):

constexpr bool IsScenario1(bool b1, bool b2, bool b3, bool b4) noexcept
{ return b1 && b2 && b3 && b4; }

constexpr bool IsScenario2(bool b1, bool b2, bool b3, bool b4) noexcept
{ return b1 && b2 && b3 && !b4; }

constexpr bool IsScenario3(bool b1, bool b2, bool b3, bool b4) noexcept
{ return b1 && !b2 && !b3 && !b4; }

Machen Sie diese Klassenmethoden wenn möglich (wie in der OP-Lösung). Sie können Variablen innerhalb Ihrer Funktion verwenden, wenn Sie nicht glauben, dass Sie die Logik wiederverwenden werden:

const auto is_scenario_1 = bValue1 && bValue2 && bValue3 && bValue4;
const auto is_scenario_2 = bvalue1 && bvalue2 && bValue3 && !bValue4;
const auto is_scenario_3 = bValue1 && !bValue2 && !bValue3 && !bValue4;

Der Compiler wird höchstwahrscheinlich feststellen, dass alle Szenarien falsch sind, wenn bValue1 falsch ist. Mach dir keine Sorgen, dass es schnell geht, nur korrekt und lesbar. Wenn Sie Ihren Code profilieren und feststellen, dass dies ein Engpass ist, weil der Compiler bei -O2 oder höher suboptimalen Code generiert hat, versuchen Sie, ihn neu zu schreiben.

AC / C ++ Weg

bool scenario[3][4] = {{true, true, true, true}, 
                        {true, true, true, false}, 
                        {true, false, false, false}};

bool CheckScenario(bool bValue1, bool bValue2, bool bValue3, bool bValue4)
{
    bool temp[] = {bValue1, bValue2, bValue3, bValue4};
    for(int i = 0 ; i < sizeof(scenario) / sizeof(scenario[0]); i++)
    {
        if(memcmp(temp, scenario[i], sizeof(temp)) == 0)
            return true;
    }
    return false;
}

Dieser Ansatz ist skalierbar, als ob die Anzahl der gültigen Bedingungen zunimmt. Sie können einfach weitere davon zur Szenarioliste hinzufügen.

Es ist leicht zu bemerken, dass die ersten beiden Szenarien ähnlich sind - sie teilen die meisten Bedingungen. Wenn Sie auswählen möchten, in welchem ​​Szenario Sie sich gerade befinden, können Sie es folgendermaßen schreiben (es handelt sich um eine modifizierte @ gian-paolo -Lösung):

bool valid = false;
if(bValue1 && bValue2 && bValue3)
{
    if (bValue4)
        valid = true; //scenario 1
    else if (!bValue4)
        valid = true; //scenario 2
}
else if (bValue1 && !bValue2 && !bValue3 && !bValue4)
    valid = true; //scenario 3

Wenn Sie weiter gehen, können Sie feststellen, dass der erste Boolesche Wert immer wahr sein muss. Dies ist eine Eingabebedingung, sodass Sie am Ende Folgendes erhalten können:

bool valid = false;
if(bValue1)
{
    if(bValue2 && bValue3)
    {
        if (bValue4)
            valid = true; //scenario 1
        else if (!bValue4)
            valid = true; //scenario 2
    }
    else if (!bValue2 && !bValue3 && !bValue4)
        valid = true; //scenario 3
}

Darüber hinaus können Sie jetzt deutlich erkennen, dass bValue2 und bValue3 in gewisser Weise miteinander verbunden sind. Sie können ihren Status in einige externe Funktionen oder Variablen mit einem passenderen Namen extrahieren (dies ist jedoch nicht immer einfach oder angemessen):

bool valid = false;
if(bValue1)
{
    bool bValue1and2 = bValue1 && bValue2;
    bool notBValue1and2 = !bValue2 && !bValue3;
    if(bValue1and2)
    {
        if (bValue4)
            valid = true; //scenario 1
        else if (!bValue4)
            valid = true; //scenario 2
    }
    else if (notBValue1and2 && !bValue4)
        valid = true; //scenario 3
}

Dies zu tun hat einige Vor- und Nachteile:

• Die Bedingungen sind kleiner, daher ist es einfacher, darüber nachzudenken.
• Es ist einfacher, eine nette Umbenennung vorzunehmen, um diese Bedingungen verständlicher zu machen.
• aber sie müssen den Umfang verstehen,
• außerdem ist es starrer

Wenn Sie vorhersagen, dass sich Änderungen an der obigen Logik ergeben werden, sollten Sie einen einfacheren Ansatz verwenden, wie er von @ gian-paolo dargestellt wird .

Andernfalls sollten Sie mein letztes Code-Snippet in Betracht ziehen, wenn diese Bedingungen gut etabliert sind und eine Art "solide Regeln" darstellen, die sich nie ändern werden.

Wie von mch vorgeschlagen, können Sie Folgendes tun:

if(!((bValue1 && bValue2 && bValue3) || 
  (bValue1 && !bValue2 && !bValue3 && !bValue4))
)

Dabei deckt die erste Zeile die beiden ersten guten Fälle ab und die zweite Zeile den letzten.

Live Demo, wo ich herumgespielt habe und es deine Fälle passiert.

Eine kleine Variation von @ GianPaolos feiner Antwort, die einige vielleicht leichter zu lesen finden:

bool any_of_three_scenarios(bool v1, bool v2, bool v3, bool v4)
{
  return (v1 &&  v2 &&  v3 &&  v4)  // scenario 1
      || (v1 &&  v2 &&  v3 && !v4)  // scenario 2
      || (v1 && !v2 && !v3 && !v4); // scenario 3
}

if (any_of_three_scenarios(bValue1,bValue2,bValue3,bValue4))
{
  // ...
}

Jede Antwort ist zu komplex und schwer zu lesen. Die beste Lösung hierfür ist eine switch()Aussage. Es ist sowohl lesbar als auch erleichtert das Hinzufügen / Ändern zusätzlicher Fälle. Compiler sind auch gut darin, switch()Anweisungen zu optimieren .

switch( (bValue4 << 3) | (bValue3 << 2) | (bValue2 << 1) | (bValue1) )
{
    case 0b1111:
        // scenario 1
        break;

    case 0b0111:
        // scenario 2
        break;

    case 0b0001:
        // scenario 3
        break;

    default:
        // fault condition
        break;
}

Sie können natürlich Konstanten und ODER-Verknüpfungen in den caseAnweisungen verwenden, um die Lesbarkeit zu verbessern.

Aus Gründen der Übersichtlichkeit würde ich auch Verknüpfungsvariablen verwenden. Wie bereits erwähnt, entspricht Szenario 1 Szenario 2, da der Wert von bValue4 die Wahrheit dieser beiden Szenarien nicht beeinflusst.

bool MAJORLY_TRUE=bValue1 && bValue2 && bValue3
bool MAJORLY_FALSE=!(bValue2 || bValue3 || bValue4)

dann wird dein Ausdruck:

if (MAJORLY_TRUE || (bValue1 && MAJORLY_FALSE))
{
     // do something
}
else
{
    // There is some error
}

Das Vergeben aussagekräftiger Namen für MAJORTRUE- und MAJORFALSE-Variablen (sowie für bValue * -Vars) würde die Lesbarkeit und Wartung erheblich verbessern.

Konzentrieren Sie sich auf die Lesbarkeit des Problems, nicht auf die spezifische "if" -Anweisung.

Dies führt zwar zu mehr Codezeilen, und einige halten dies möglicherweise für übertrieben oder unnötig. Ich würde vorschlagen, dass das Abstrahieren Ihrer Szenarien von den spezifischen Booleschen Werten der beste Weg ist, um die Lesbarkeit aufrechtzuerhalten.

Durch die Aufteilung der Dinge in Klassen (Sie können einfach nur Funktionen oder ein anderes von Ihnen bevorzugtes Tool verwenden) mit verständlichen Namen können wir die Bedeutung hinter jedem Szenario viel einfacher aufzeigen. Noch wichtiger ist, dass es in einem System mit vielen beweglichen Teilen einfacher ist, Ihre vorhandenen Systeme zu warten und mit ihnen zu verbinden (auch wenn so viel zusätzlicher Code erforderlich ist).

#include <iostream>
#include <vector>
using namespace std;

// These values would likely not come from a single struct in real life
// Instead, they may be references to other booleans in other systems
struct Values
{
    bool bValue1; // These would be given better names in reality
    bool bValue2; // e.g. bDidTheCarCatchFire
    bool bValue3; // and bDidTheWindshieldFallOff
    bool bValue4;
};

class Scenario
{
public:
    Scenario(Values& values)
    : mValues(values) {}

    virtual operator bool() = 0;

protected:
    Values& mValues;    
};

// Names as examples of things that describe your "scenarios" more effectively
class Scenario1_TheCarWasNotDamagedAtAll : public Scenario
{
public:
    Scenario1_TheCarWasNotDamagedAtAll(Values& values) : Scenario(values) {}

    virtual operator bool()
    {
        return mValues.bValue1
        && mValues.bValue2
        && mValues.bValue3
        && mValues.bValue4;
    }
};

class Scenario2_TheCarBreaksDownButDidntGoOnFire : public Scenario
{
public:
    Scenario2_TheCarBreaksDownButDidntGoOnFire(Values& values) : Scenario(values) {}

    virtual operator bool()
    {
        return mValues.bValue1
        && mValues.bValue2
        && mValues.bValue3
        && !mValues.bValue4;
    }   
};

class Scenario3_TheCarWasCompletelyWreckedAndFireEverywhere : public Scenario
{
public:
    Scenario3_TheCarWasCompletelyWreckedAndFireEverywhere(Values& values) : Scenario(values) {}

    virtual operator bool()
    {
        return mValues.bValue1
        && !mValues.bValue2
        && !mValues.bValue3
        && !mValues.bValue4;
    }   
};

Scenario* findMatchingScenario(std::vector<Scenario*>& scenarios)
{
    for(std::vector<Scenario*>::iterator it = scenarios.begin(); it != scenarios.end(); it++)
    {
        if (**it)
        {
            return *it;
        }
    }
    return NULL;
}

int main() {
    Values values = {true, true, true, true};
    std::vector<Scenario*> scenarios = {
        new Scenario1_TheCarWasNotDamagedAtAll(values),
        new Scenario2_TheCarBreaksDownButDidntGoOnFire(values),
        new Scenario3_TheCarWasCompletelyWreckedAndFireEverywhere(values)
    };

    Scenario* matchingScenario = findMatchingScenario(scenarios);

    if(matchingScenario)
    {
        std::cout << matchingScenario << " was a match" << std::endl;
    }
    else
    {
        std::cout << "No match" << std::endl;
    }

    // your code goes here
    return 0;
}

Es kommt darauf an, was sie darstellen.

Wenn beispielsweise 1 ein Schlüssel ist und 2 und 3 zwei Personen sind, die zustimmen müssen (es sei denn, sie sind sich einig, dass NOTsie eine dritte Person benötigen - 4 -, um dies zu bestätigen), ist möglicherweise am besten lesbar:

1 &&
    (
        (2 && 3)   
        || 
        ((!2 && !3) && !4)
    )

auf vielfachen Wunsch:

Key &&
    (
        (Alice && Bob)   
        || 
        ((!Alice && !Bob) && !Charlie)
    )

Die bitweise Bedienung sieht sehr sauber und verständlich aus.

int bitwise = (bValue4 << 3) | (bValue3 << 2) | (bValue2 << 1) | (bValue1);
if (bitwise == 0b1111 || bitwise == 0b0111 || bitwise == 0b0001)
{
    //satisfying condition
}

Ich bezeichne a, b, c, d aus Gründen der Klarheit und A, B, C, D für Ergänzungen

bValue1 = a (!A)
bValue2 = b (!B)
bValue3 = c (!C)
bValue4 = d (!D)

Gleichung

1 = abcd + abcD + aBCD
  = a (bcd + bcD + BCD)
  = a (bc + BCD)
  = a (bcd + D (b ^C))

Verwenden Sie alle Gleichungen, die zu Ihnen passen.

If (!bValue1 || (bValue2 != bValue3) || (!bValue4 && bValue2))
{
// you have a problem
}

• b1 muss immer wahr sein
• b2 muss immer gleich b3 sein
• und b4 kann nicht falsch sein, wenn b2 (und b3) wahr sind

einfach

Nur eine persönliche Präferenz gegenüber der akzeptierten Antwort, aber ich würde schreiben:

bool valid = false;
// scenario 1
valid = valid || (bValue1 && bValue2 && bValue3 && bValue4);
// scenario 2
valid = valid || (bValue1 && bValue2 && bValue3 && !bValue4);
// scenario 3
valid = valid || (bValue1 && !bValue2 && !bValue3 && !bValue4);

Angenommen, Sie können nur die Szenarioprüfung ändern, würde ich mich auf die Lesbarkeit konzentrieren und die Prüfung einfach in eine Funktion einbinden, damit Sie sie einfach aufrufen können if(ScenarioA()).

Angenommen, Sie möchten / müssen dies tatsächlich optimieren, würde ich empfehlen, die eng verknüpften Booleschen Werte in konstante Ganzzahlen umzuwandeln und Bitoperatoren für sie zu verwenden

public class Options {
  public const bool A = 2; // 0001
  public const bool B = 4; // 0010
  public const bool C = 16;// 0100
  public const bool D = 32;// 1000
//public const bool N = 2^n; (up to n=32)
}

...

public isScenario3(int options) {
  int s3 = Options.A | Options.B | Options.C;
  // for true if only s3 options are set
  return options == s3;
  // for true if s3 options are set
  // return options & s3 == s3
}

Dies macht das Ausdrücken der Szenarien so einfach wie das Auflisten der Teile, ermöglicht es Ihnen, mit einer switch-Anweisung zum richtigen Zustand zu springen und andere Entwickler zu verwirren, die dies noch nicht gesehen haben. (C # RegexOptions verwendet dieses Muster zum Setzen von Flags. Ich weiß nicht, ob es ein Beispiel für eine C ++ - Bibliothek gibt.)

Verschachtelte ifs könnten für manche Menschen leichter zu lesen sein. Hier ist meine Version

bool check(int bValue1, int bValue2, int bValue3, int bValue4)
{
  if (bValue1)
  {
    if (bValue2)
    {
      // scenario 1-2
      return bValue3;
    }
    else
    {
      // scenario 3
      return !bValue3 && !bValue4;
    }
  }

  return false;
}

Auf diese Frage wurden mehrere richtige Antworten gegeben, aber ich würde eine andere Ansicht vertreten: Wenn der Code zu kompliziert aussieht, stimmt etwas nicht ganz . Der Code ist schwer zu debuggen und eher "nur zur einmaligen Verwendung".

Wenn wir im wirklichen Leben eine Situation wie diese finden:

         Scenario 1 | Scenario 2 | Scenario 3
bValue1: true       | true       | true
bValue2: true       | true       | false
bValue3: true       | true       | false
bValue4: true       | false      | false

Wenn vier Zustände durch ein so genaues Muster verbunden sind, haben wir es mit der Konfiguration einer "Entität" in unserem Modell zu tun .

Eine extreme Metapher ist, wie wir einen "Menschen" in einem Modell beschreiben würden, wenn wir uns ihrer Existenz als einheitliche Einheiten mit Komponenten, die in bestimmten Freiheitsgraden verbunden sind, nicht bewusst wären: Wir müssten unabhängige Zustände von "Torsos" beschreiben. "Arme", "Beine" und "Kopf", was es kompliziert machen würde, das beschriebene System zu verstehen. Ein unmittelbares Ergebnis wären unnatürlich komplizierte boolesche Ausdrücke.

Offensichtlich ist der Weg zur Reduzierung der Komplexität die Abstraktion, und ein Werkzeug der Wahl in c ++ ist das Objektparadigma .

Die Frage ist also: warum gibt es so ein Muster? Was ist das und was repräsentiert es?

Da wir die Antwort nicht kennen, können wir auf eine mathematische Abstraktion zurückgreifen: das Array : Wir haben drei Szenarien, von denen jedes jetzt ein Array ist.

                0   1   2   3
Scenario 1:     T   T   T   T
Scenario 2:     T   T   T   F
Scenario 3:     T   F   F   F

An diesem Punkt haben Sie Ihre Erstkonfiguration. als Array. Z.Bstd::array hat einen Gleichheitsoperator:

An welchem ​​Punkt wird Ihre Syntax:

if( myarray == scenario1 ) {
  // arrays contents are the same

} 
else if ( myarray == scenario2 ) {
  // arrays contents are the same

} 

else if ( myarray == scenario3 ) {
  // arrays contents are the same

} 
else {
  // not the same

}

Genau wie die Antwort von Gian Paolo ist sie kurz, klar und leicht zu überprüfen / zu debuggen. In diesem Fall haben wir die Details der booleschen Ausdrücke an den Compiler delegiert.

Sie müssen sich keine Gedanken über ungültige Kombinationen von Booleschen Flags machen, wenn Sie die Booleschen Flags entfernen.

Die akzeptablen Werte sind:

         Scenario 1 | Scenario 2 | Scenario 3
bValue1: true       | true       | true
bValue2: true       | true       | false
bValue3: true       | true       | false
bValue4: true       | false      | false

Sie haben eindeutig drei Zustände (Szenarien). Es wäre besser, dies zu modellieren und die booleschen Eigenschaften aus diesen Zuständen abzuleiten , nicht umgekehrt.

enum State
{
    scenario1,
    scenario2,
    scenario3,
};

inline bool isValue1(State s)
{
    // (Well, this is kind of silly.  Do you really need this flag?)
    return true;
}

inline bool isValue2(State s)
{
    switch (s)
    {
        case scenario1:
        case scenario2:
            return true;
        case scenario3:
            return false;
    }
}

inline bool isValue3(State s)
{
    // (This is silly too.  Do you really need this flag?)
    return isValue2(s);
}

inline bool isValue4(State s)
{
    switch (s)
    {
        case scenario1:
            return true;
        case scenario2:
        case scenario3:
            return false;
    }
}

Dies ist definitiv mehr Code als in Gian Paolos Antwort , aber abhängig von Ihrer Situation könnte dies viel wartbarer sein:

• Es gibt eine zentrale Reihe von Funktionen, die geändert werden müssen, wenn zusätzliche boolesche Eigenschaften oder Szenarien hinzugefügt werden.
  • Zum Hinzufügen von Eigenschaften muss nur eine einzige Funktion hinzugefügt werden.
  • Wenn Sie ein Szenario hinzufügen und Compiler-Warnungen über nicht behandelte enumFälle in switchAnweisungen aktivieren , werden Eigenschafts-Getter abgefangen , die dieses Szenario nicht behandeln.
• Wenn Sie die booleschen Eigenschaften dynamisch ändern müssen, müssen Sie ihre Kombinationen nicht überall erneut validieren. Anstatt einzelne boolesche Flags umzuschalten (was zu ungültigen Kombinationen von Flags führen könnte), hätten Sie stattdessen eine Zustandsmaschine, die von einem Szenario in ein anderes übergeht.

Dieser Ansatz hat auch den Nebeneffekt, sehr effizient zu sein.

Meine 2 Cent: deklarieren Sie eine variable Summe (Integer) damit

if(bValue1)
{
  sum=sum+1;
}
if(bValue2)
{
  sum=sum+2;
}
if(bValue3)
{
  sum=sum+4;
}
if(bValue4)
{
  sum=sum+8;
}

Prüfen Sie die Summe anhand der gewünschten Bedingungen und fertig. Auf diese Weise können Sie in Zukunft problemlos weitere Bedingungen hinzufügen, sodass das Lesen recht einfach ist.

Die akzeptierte Antwort ist in Ordnung, wenn Sie nur 3 Fälle haben und die Logik für jeden einfach ist.

Wenn die Logik für jeden Fall komplizierter wäre oder es viel mehr Fälle gibt, ist es weitaus besser, das Entwurfsmuster der Verantwortungskette zu verwenden.

Sie erstellen eine, BaseValidatordie einen Verweis auf a BaseValidatorund eine Methode auf validateund eine Methode zum Aufrufen der Validierung für den referenzierten Validator enthält.

class BaseValidator {
    BaseValidator* nextValidator;

    public:
    BaseValidator() {
        nextValidator = 0;
    }

    void link(BaseValidator validator) {
        if (nextValidator) {
            nextValidator->link(validator);
        } else {
            nextValidator = validator;
        }
    }

    bool callLinkedValidator(bool v1, bool v2, bool v3, bool v4) {
        if (nextValidator) {
            return nextValidator->validate(v1, v2, v3, v4);
        }

        return false;
    }

    virtual bool validate(bool v1, bool v2, bool v3, bool v4) {
        return false;
    }
}

Anschließend erstellen Sie eine Reihe von Unterklassen, die von der erben BaseValidator, und überschreiben die validateMethode mit der für jeden Validator erforderlichen Logik.

class Validator1: public BaseValidator {
    public:
    bool validate(bool v1, bool v2, bool v3, bool v4) {
        if (v1 && v2 && v3 && v4) {
            return true;
        }

        return nextValidator->callLinkedValidator(v1, v2, v3, v4);
    }
}

Dann ist es einfach, jeden Ihrer Validatoren zu instanziieren und jeden von ihnen als Wurzel der anderen festzulegen:

Validator1 firstValidator = new Validator1();
Validator2 secondValidator = new Validator2();
Validator3 thirdValidator = new Validator3();
firstValidator.link(secondValidator);
firstValidator.link(thirdValidator);
if (firstValidator.validate(value1, value2, value3, value4)) { ... }

Im Wesentlichen hat jeder Validierungsfall eine eigene Klasse, die dafür verantwortlich ist, (a) festzustellen, ob die Validierung mit dieser übereinstimmt Fall , und (b) die Validierung an eine andere Person in der Kette zu senden, wenn dies nicht der Fall ist.

Bitte beachten Sie, dass ich mit C ++ nicht vertraut bin. Ich habe versucht, die Syntax einiger Beispiele zu finden, die ich online gefunden habe. Wenn dies jedoch nicht funktioniert, behandeln Sie sie eher wie einen Pseudocode. Ich habe auch ein vollständiges funktionierendes Python-Beispiel unten, das bei Bedarf als Grundlage verwendet werden kann.

class BaseValidator:
    def __init__(self):
        self.nextValidator = 0

    def link(self, validator):
        if (self.nextValidator):
            self.nextValidator.link(validator)
        else:
            self.nextValidator = validator

    def callLinkedValidator(self, v1, v2, v3, v4):
        if (self.nextValidator):
            return self.nextValidator.validate(v1, v2, v3, v4)

        return False

    def validate(self, v1, v2, v3, v4):
        return False

class Validator1(BaseValidator):
    def validate(self, v1, v2, v3, v4):
        if (v1 and v2 and v3 and v4):
            return True
        return self.callLinkedValidator(v1, v2, v3, v4)

class Validator2(BaseValidator):
    def validate(self, v1, v2, v3, v4):
        if (v1 and v2 and v3 and not v4):
            return True
        return self.callLinkedValidator(v1, v2, v3, v4)

class Validator3(BaseValidator):
    def validate(self, v1, v2, v3, v4):
        if (v1 and not v2 and not v3 and not v4):
            return True
        return self.callLinkedValidator(v1, v2, v3, v4)

firstValidator = Validator1()
secondValidator = Validator2()
thirdValidator = Validator3()
firstValidator.link(secondValidator)
firstValidator.link(thirdValidator)
print(firstValidator.validate(False, False, True, False))

Auch hier finden Sie diesen Overkill möglicherweise für Ihr spezielles Beispiel, aber er erzeugt viel saubereren Code, wenn Sie am Ende eine weitaus kompliziertere Reihe von Fällen haben, die erfüllt werden müssen.

Ein einfacher Ansatz besteht darin, die Antwort zu finden, die Sie für akzeptabel halten.

Ja = (boolean1 && boolean2 && boolean3 && boolean4) + + ...

Vereinfachen Sie nun nach Möglichkeit die Gleichung mit der Booleschen Algebra.

wie in diesem Fall kombinieren sich akzeptabel1 und 2 zu (boolean1 && boolean2 && boolean3).

Daher lautet die endgültige Antwort:

(boolean1 && boolean2 && boolean3) || 
((boolean1 && !boolean2 && !boolean3 && !boolean4)

verwenden Bit - Feld :

unoin {
  struct {
    bool b1: 1;
    bool b2: 1;
    bool b3: 1;
    bool b4: 1;
  } b;
  int i;
} u;

// set:
u.b.b1=true;
...

// test
if (u.i == 0x0f) {...}
if (u.i == 0x0e) {...}
if (u.i == 0x08) {...}

PS :

Das ist sehr schade für CPPer. Aber UB ist nicht meine Sorge, überprüfen Sie es unter http://coliru.stacked-crooked.com/a/2b556abfc28574a1 .