4つのブール値がいくつかのケースに一致するかどうかをチェックするロジックを改善する方法

私には4つのbool値があります。

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

許容値は次のとおりです。

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

したがって、たとえば、このシナリオは受け入れられません。

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

現時点では、if悪いシナリオを検出するために次のステートメントを考え出しました。

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

そのステートメントロジックを改善/簡略化できますか？

私は読みやすさを目指しています。シナリオは3つしかありません。3つの個別のifで対処してください。

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

読みやすく、デバッグしやすい、IMHO。また、のwhichScenario処理中に変数を割り当てることができますif。

たった3つのシナリオでは、「最初の3つの値がtrueの場合、4番目の値をチェックしないようにすることができます」というようなことはしません。コードの読み取りと保守が難しくなります。

エレガントなソリューションではありません 多分 確かに、しかしこの場合は大丈夫です：簡単で読みやすいです。

ロジックがさらに複雑になった場合は、そのコードを破棄し、使用可能なさまざまなシナリオを格納するために何かを使用することを検討してください（Zladeckが示唆しているように）。

私はこの答えで与えられた最初の提案が本当に大好きです：読みやすく、エラーが発生しにくく、保守可能

（ほぼ）オフトピック：

ここStackOverflowでは、あまり多くの答えを書きません。上記の受け入れられた回答が私の歴史でこれまでで最も高く評価された回答である（私が考える前に5〜10票を超えることは決してなかった）のは本当に面白いですが、実際には、私が通常は「正しい」方法であるとは考えていません。

しかし、単純さはしばしば「それを行う正しい方法」であり、多くの人々はこれを考えているようであり、私は私よりももっと考えるべきです:)

シンプルさと読みやすさを目指しています。

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

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

シナリオの名前とフラグの名前を説明的なものに置き換えてください。特定の問題に意味がある場合は、この代替案を検討できます。

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

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

ここで重要なのは述語論理ではありません。それはあなたのドメインを説明し、あなたの意図を明確に表現しています。ここで重要なのは、すべての入力と中間変数に適切な名前を付けることです。適切な変数名が見つからない場合は、問題を間違った方法で説明している可能性があります。

Karnaughマップを使用して、シナリオを論理方程式に縮小できます。私は、4つの変数の回路を備えたオンラインカルノーマップソルバーを使用しました。

これにより、

に変更A, B, C, DするとbValue1, bValue2, bValue3, bValue4、これは他に何もありません。

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

したがって、ifステートメントは次のようになります。

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

• Karnaughマップは、評価する必要のある変数や条件が多い場合に特に役立ちますtrue。
• trueシナリオを論理方程式に変換した後、シナリオを示す関連コメントを追加することをお勧めしますtrue。

ここでの本当の問題は、別の開発者（または作成者でさえ）が数か月後にこのコードを変更しなければならないときに何が起こるかです。

これをビットフラグとしてモデル化することをお勧めします。

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");

より多くのシナリオまたはより多くのフラグがある場合、フラグを使用するよりもテーブルアプローチの方が読みやすく、拡張可能です。新しいシナリオをサポートするには、テーブルの別の行が必要です。

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");
}

私の以前の答えはすでに受け入れられた答えです。ここでは、読みやすく、簡単で、この場合は将来の変更に対応できると思うものを追加します。

@ZdeslavVojkovicの答え（私はかなり良いと思います）から始めて、これを思いつきました：

#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;
}

こちらの職場でご覧ください

まあ、それは私が通常目指している「エレガントで保守可能な」（IMHO）ソリューションですが、実際には、OPの場合、以前の「ifsの束」の回答は、エレガントでも保守可能でなくても、OP要件によりよく適合します。

他のアプローチも提出したいと思います。

私の考えは、ブール値を整数に変換してから、可変個のテンプレートを使用して比較することです。

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
    }
}

このシステムが入力として最大32のブールをサポートできることに注目してください。unsignedをunsigned long long（またはuint64_t）に置き換えると、サポートが64ケースに増加します。が気に入らない場合はif (summary != 0b1111u && summary != 0b1110u && summary != 0b1000u)、さらに別の可変テンプレートテンプレートメソッドを使用することもできます。

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
    }
}

簡略版は次のとおりです。

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

もちろん、この解決策は元の解決策よりも難読化されていることに注意してください。その意味は理解しにくいかもしれません。

更新：コメント内のMSalterはさらに単純な式を見つけました：

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

テーブルをできるだけ直接プログラムに変換することを検討してください。ロジックで模倣するのではなく、テーブルに基づいてプログラムを実行します。

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;
}

今

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

これは可能な限り直接、真理値表をコンパイラーにエンコードします。

ライブの例。

std::any_of直接使用することもできます：

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;
}) {
}

コンパイラーはコードをインライン化し、反復を排除して独自のロジックを構築できます。一方、コードは、問題をどのように考え出したかを正確に反映しています。

誰かが私の解決策を示すように提案したコメントのように、私はここで私の答えを提供しています。皆さんの洞察に感謝したいと思います。

最後に、3つの新しい「シナリオ」booleanメソッドを追加することにしました。

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));
}

次に、これらを私の検証ルーチンに次のように適用することができました。

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

私のライブアプリケーションでは、4つのブール値は実際には DWORDには4つの値がエンコードされているされます。

再びありがとうございました。

OPのソリューションはそれを正確に行いますが、シナリオに名前を付けるための回答はありません。

私には、各シナリオのコメントを変数名または関数名にカプセル化するのが最善です。名前よりもコメントを無視する可能性が高く、ロジックが将来変更される場合は、コメントよりも名前を変更する可能性が高くなります。コメントをリファクタリングすることはできません。

関数の外でこれらのシナリオを再利用する予定がある場合（または必要に応じて）、評価する内容を示す関数を作成します（constexpr/ noexceptオプションですが推奨）。

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; }

可能であれば、これらのクラスメソッドを作成します（OPのソリューションのように）。ロジックを再利用する予定がない場合は、関数内で変数を使用できます。

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;

コンパイラーは、bValue1がfalseの場合、すべてのシナリオがfalseであると分類する可能性が最も高くなります。高速で正確で読みやすいものにする必要はありません。コードをプロファイリングし、コンパイラが-O2以上で最適ではないコードを生成したためにこれがボトルネックになっている場合は、コードを書き直してみてください。

AC / C ++の方法

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;
}

このアプローチは、有効な条件の数が増えるかのようにスケーラブルであり、シナリオリストに条件を追加するだけです。

最初の2つのシナリオは似ていることに簡単に気づくでしょう-それらはほとんどの条件を共有しています。現在のシナリオを選択したい場合は、次のように書くことができます（これは、@ gian-paoloのソリューションを変更したものです）。

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

さらに進むと、最初のブール値は常にtrueである必要があることに気づくでしょう。これはエントリー条件なので、次のようになります。

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
}

さらに、bValue2とbValue3がいくぶん接続されていることがはっきりとわかります。それらの状態を、より適切な名前の外部関数または変数に抽出できます（ただし、これは必ずしも簡単または適切ではありません）。

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
}

この方法で行うと、いくつかの利点と欠点があります。

• 条件は小さいので、それらについて推論するのは簡単です、
• これらの条件をわかりやすくするために、名前を変更するほうが簡単です。
• しかし、彼らは範囲を理解する必要があります、
• さらにそれはより堅いです

上記のロジックに変更があると予測される場合は、@ gian-paoloで提示されているより簡単な方法を使用する必要があります。

それ以外の場合、これらの条件が十分に確立されており、変更されない「堅固なルール」の一種である場合は、最後のコードスニペットを検討してください。

mchで提案されているように、次のことができます。

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

最初の行は最初の2つの良いケースをカバーし、2番目の行は最後のケースをカバーします。

Live Demo、私が遊んだところ、それはあなたの事件を通過します。

@GianPaoloの細かい回答のわずかなバリエーション。

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))
{
  // ...
}

すべての答えは非常に複雑で読みにくいです。これに対する最善の解決策はswitch()ステートメントです。どちらも読みやすく、追加のケースの追加/変更が簡単になります。コンパイラーはswitch()ステートメントの最適化にも優れています。

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;
}

もちろん、定数を使用してcaseステートメントでORすることで、さらに読みやすくすることができます。

わかりやすくするためにショートカット変数も使用します。前述のように、bValue4の値はこれら2つのシナリオの真実に影響を与えないため、シナリオ1はシナリオ2と同じです。

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

次に、あなたの表現が始まります：

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

MAJORTRUE変数とMAJORFALSE変数に（そして実際にはbValue *変数に）意味のある名前を付けると、可読性と保守性が大幅に向上します。

特定の「if」ステートメントではなく、問題の読みやすさに焦点を当てます。

これにより、より多くのコード行が生成されますが、過剰または不必要と見なされる場合もあります。特定のブール値からシナリオを抽象化することが、読みやすさを維持するための最良の方法であることをお勧めします。

わかりやすい名前でクラスに分割することで（関数や他の好きなツールを自由に使用できます）、各シナリオの背後にある意味をはるかに簡単に示すことができます。さらに重要なことは、多くの可動部分があるシステムでは、既存のシステムの保守と参加が容易になります（ここでも、余分なコードがいくら含まれていても）。

#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;
}

それは彼らが何を表すかに依存します。

たとえば場合1が鍵であり、そして2と3は、（彼らは上で同意する場合を除き、同意しなければならない2人ですNOT、彼らは三人必要- 4 -確認するために）最も読みやすいのかもしれません。

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

人気のリクエストによる：

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

ビット演算を行うことは、非常にクリーンで理解しやすいように見えます。

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

私は明確にするためにa、b、c、dを示し、補数のためにA、B、C、Dを示しています

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

方程式

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

あなたに合った方程式を使ってください。

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

• b1は常に真でなければならない
• b2は常にb3と等しくなければなりません
• b2（およびb3）がtrueの場合、b4をfalseにすることはできません

簡単な

受け入れられた答えよりも個人的な好みですが、私は書きます：

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);

最初に、シナリオチェックのみを変更できると仮定して、読みやすさに焦点を当て、チェックを関数にラップするだけで、を呼び出すことができますif(ScenarioA())。

今、あなたが実際にこれを最適化したい/必要としていると仮定すると、密にリンクされたブール値を定数整数に変換し、それらにビット演算子を使用することをお勧めします

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
}

これにより、シナリオの一部をリストするのと同じくらい簡単にシナリオを表現できるようになり、switchステートメントを使用して適切な条件にジャンプし、これをこれまでに見たことのない他の開発者を混乱させることができます。（C＃RegexOptionsはこのパターンを使用してフラグを設定します。C++ライブラリの例があるかどうかはわかりません）

ネストされたifsは、一部の人にとっては読みやすいかもしれません。これが私のバージョンです

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;
}

この質問にはいくつかの正解が出されていますが、私は別の見方をします。コードが複雑すぎるように見える場合、何かが正しくありません。コードはデバッグが難しく、「1回限りの使用」になる可能性が高くなります。

実生活では、次のような状況が見つかった場合：

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

4つの状態がこのような正確なパターンで接続されている場合、モデル内の「エンティティ」の構成を処理しています。

極端なメタファーは、特定の自由度に接続されたコンポーネントを持つ単一のエンティティとしての存在を認識していなかった場合のモデルでの「人間」の記述方法です。「胴体」の独立した状態を記述する必要があります。 「腕」、「脚」、「頭」。説明したシステムを理解するのが複雑になります。即時の結果は、不自然に複雑なブール式になります。

明らかに、複雑さを軽減する方法は抽象化であり、c ++で選択するツールはオブジェクトパラダイムです。

だから問題は：なぜそのようなパターンがあるのですか？これは何ですか、何を表していますか？

答えがわからないので、数学的抽象化に頼ることができます。配列：3つのシナリオがあり、それぞれが配列になっています。

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

この時点で、初期構成が完了しています。配列として。例えばstd::array、等価演算子があります。

その時点で、構文は次のようになります。

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

}

ジャンパオロの答えと同じように、短くて明確で、簡単に検証/デバッグできます。この場合、ブール式の詳細をコンパイラーに委任しています。

ブールフラグを削除する場合は、ブールフラグの無効な組み合わせについて心配する必要はありません。

許容値は次のとおりです。

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

明らかに3つの状態（シナリオ）があります。それをモデル化し、それらの状態からブール型プロパティを導出するのが良いでしょう。逆ではありません。

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;
    }
}

これはGian Paoloの回答よりも明らかに多くのコードですが、状況によっては、はるかに保守しやすくなる可能性があります。

• 追加のブール値のプロパティまたはシナリオが追加された場合に変更する関数の中央セットがあります。
  • プロパティを追加するには、関数を1つだけ追加する必要があります。
  • シナリオを追加するenum場合、switchステートメントの未処理のケースに関するコンパイラ警告を有効にすると、そのシナリオを処理しないプロパティゲッターがキャッチされます。
• ブール値のプロパティを動的に変更する必要がある場合は、すべての場所でそれらの組み合わせを再検証する必要はありません。個々のブールフラグを切り替える（フラグの組み合わせが無効になる可能性があります）代わりに、1つのシナリオから別のシナリオに遷移するステートマシンを使用します。

このアプローチには、非常に効率的であるという副次的な利点もあります。

私の2セント：変数の合計（整数）を宣言して、

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

あなたが望む条件に対して合計をチェックしてください、それだけです。このようにして、将来さらに簡単に条件を追加して、読みやすくすることができます。

受け入れられた答えは、3つのケースしかなく、それぞれのロジックが単純な場合に問題ありません。

ただし、各ケースのロジックがより複雑である場合、またはさらに多くのケースがある場合は、責任の連鎖を使用する方がはるかに優れたオプションです。設計パターン。

へのBaseValidator参照を含むを作成し、参照先のバリデーターの検証を呼び出すためのメソッドとBaseValidatorメソッドを作成しますvalidate。

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;
    }
}

次にBaseValidator、から継承する多数のサブクラスを作成し、validate各バリデータに必要なロジックでメソッドをオーバーライドします。

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);
    }
}

次に、それを使用するのは簡単です。各バリデーターをインスタンス化し、それぞれを他のルートに設定します。

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)) { ... }

本質的に、各検証ケースには独自のクラスがあり、（a）検証がそのケースと一致するかどうかを判別し、（b）一致しない場合はチェーン内の他の誰かに検証を送信します。

私はC ++に慣れていないことに注意してください。オンラインで見つけたいくつかの例の構文と一致させようとしましたが、これが機能しない場合は、疑似コードのように扱います。また、必要に応じて基礎として使用できる完全な動作するPythonの例を以下に示します。

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))

繰り返しになりますが、特定の例ではこのやり過ぎが見つかるかもしれませんが、満たす必要のあるはるかに複雑なケースのセットになってしまうと、コードがよりクリーンになります。

簡単なアプローチは、許容できると思う答えを見つけることです。

はい=（boolean1 && boolean2 && boolean3 && boolean4）+ + ...

次に、可能であればブール代数を使用して方程式を単純化します。

この場合のように、acceptable1と2を組み合わせて (boolean1 && boolean2 && boolean3)ます。

したがって、最終的な答えは次のとおりです。

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

ビットフィールドを使用：

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：

それはCPPersにとって大きな残念です。しかし、UBは私の心配ではありません。http://coliru.stacked-crooked.com/a/2b556abfc28574a1で確認してください。