Argthtjtr

We can use a Karnaugh map and reduce your scenarios to a logical equation.
I have used the Online Karnaugh map solver with circuit for 4 variables.

This yields:

Changing A, B, C, D to bValue1, bValue2, bValue3, bValue4, this is nothing but:

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

So your if statement becomes:

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

{

    // There is some error

}

• Karnaugh Maps are particularly useful when you have many variables and many conditions which should evaluate true.


• After reducing the true scenarios to a logical equation, adding relevant comments indicating the true scenarios is good practice.

I would aim for simplicity and readability.

bool scenario1 = bValue1 && bValue2 && bValue3 && bValue4;

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

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



if (scenario1 || scenario2 || scenario3) {

    // Do whatever.

}

Make sure to replace the names of the scenarios as well as the names of the flags with something descriptive. If it makes sense for your specific problem, you could consider this alternative:

bool scenario1or2 = bValue1 && bValue2 && bValue3;

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



if (scenario1or2 || scenario3) {

    // Do whatever.

}

What's important here is not predicate logic or Karnaugh maps. It's describing your domain and clearly expressing your intent. The key here is to give all inputs and intermediary variables good names. If you can't find good variable names, it may be a sign that you are describing the problem in the wrong way.

The real question here is: what happens when another developer (or even author) must change this code few months later.

I would suggest modelling this as bit flags:

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

If there are many more scenarios or more flags, a table approach is more readable and extensible than using flags. Supporting a new scenario requires just another row in the table.

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

}

My previous answer is already the accepted answer, I add something here that I think is both readable, easy and in this case open to future modifications:

Starting with @ZdeslavVojkovic answer (which I find quite good), I came up with this:

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

}

See it at work here

Well, that's the "elegant and maintainable" (IMHO) solution I usually aim to, but really, for the OP case, my previous "bunch of ifs" answer fits better the OP requirements, even if it's not elegant nor maintainable.

(Almost) off topic:

I don't write lot of answers here at StackOverflow. It's really funny that the above accepted anwser is the most appreciated answer in my history, granting me a couple of badges at SO.

And actually is not what I usually think is the "right" way to do it.

But simplicity is often "the right way to do it", many people seems to think this and I should think it more than I do :)

I would also like to submit an other approach.

My idea is to convert the bools into an integer and then compare using variadic templates:

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

    }

}

Notice how this system can support up to 32 bools as input. replacing the unsigned with unsigned long long (or uint64_t) increases support to 64 cases.
If you dont like the if (summary != 0b1111u && summary != 0b1110u && summary != 0b1000u), you could also use yet another variadic template method:

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

    }

}

Here's a simplified version:

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

    // acceptable

} else {

    // not acceptable

}

Note, of course, this solution is more obfuscated than the original one, its meaning may be harder to understand.

Update: MSalters in the comments found an even simpler expression:

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

I'm not seeing any answers saying to name the scenarios, though the OP's solution does exactly that.

To me it is best to encapsulate the comment of what each scenario is into either a variable name or function name. You're more likely to ignore a comment than a name, and if your logic changes in the future you're more likely to change a name than a comment. You can't refactor a comment.

If you plan on reusing these scenarios outside of your function (or might want to), then make a function that says what it evaluates (constexpr/noexcept optional but recommended):

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

Make these class methods if possible (like in OP's solution). You can use variables inside of your function if you don't think you'll reuse the logic:

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;

The compiler will most likely sort out that if bValue1 is false then all scenarios are false. Don't worry about making it fast, just correct and readable. If you profile your code and find this to be a bottleneck because the compiler generated sub-optimal code at -O2 or higher then try to rewrite it.

I am only providing my answer here as in the comments someone suggested to show my solution. I want to thank everyone for their insights.

In the end I opted to add three new "scenario" boolean methods:

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

}

Then I was able to apply those my my validation routine like this:

if (!IsFirstWeekStudentItems(pEntry) && !IsSecondWeekStudentItems(pEntry) && !IsOtherWeekStudentItems(pEntry))

{

    ; Error

}

In my live application the 4 bool values are actually extracted from a DWORD which has 4 values encoded into it.

Thanks again everyone.

A C/C++ way

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;

}

This approach is scalable as if the number of valid conditions grow, you easily just add more of them to scenario list.

It's easy to notice that first two scenarios are similar - they share most of the conditions. If you want to select in which scenario you are at the moment, you could write it like this (it's a modified @gian-paolo's solution):

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

Going further, you can notice, that first boolean needs to be always true, which is an entry condition, so you can end up with:

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

}

Even more, you can now clearly see, that bValue2 and bValue3 are somewhat connected - you could extract their state to some external functions or variables with more appropriate name (this is not always easy or appropriate though):

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

}

Doing it this way have some advantages and disadvantages:

• conditions are smaller, so it's easier to reason about them,


• it's easier to do nice renaming to make these conditions more understandable,


• but, they require to understand the scope,


• moreover it's more rigid

If you predict that there will be changes to the above logic, you should use more straightforward approach as presented by @gian-paolo.

Otherwise, if these conditions are well established, and are kind of "solid rules" that will never change, consider my last code snippet.

Consider translating your tables as directly as possible into your program. Drive the program based off the table, instead of mimicing it with logic.

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;

}

now

if (is_any_of(

  std::make_tuple(bValue1, bValue2, bValue3, bValue4),

  {

    {true, true, true, true},

    {true, true, true, false},

    {true, false, false, false}

  }

))

this directly as possible encodes your truth table into the compiler.

Live example.

You could also use std::any_of directly:

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;

}) {

}

the compiler can inline the code, and eliminate any iteration and build its own logic for you. Meanwhile, your code reflects exactly how you concieved of the problem.

I would also use shortcut variables for clarity. As noted earlier scenario 1 equals to scenario 2, because the value of bValue4 doesn't influence the truth of those two scenarios.

bool MAJORLY_TRUE=bValue1 && bValue2 && bValue3

bool MAJORLY_FALSE=!(bValue2 || bValue3 || bValue4)

then your expression beomes:

if (MAJORLY_TRUE || (bValue1 && MAJORLY_FALSE))

{

     // do something

}

else

{

    // There is some error

}

Giving meaningful names to MAJORTRUE and MAJORFALSE variables (as well as actually to bValue* vars) would help a lot with readability and maintenance.

As suggested by mch, you could do:

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

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

)

where the first line covers the two first good cases, and the second line covers the last one.

Live Demo, where I played around and it passes your cases.

Focus on readability of the problem, not the specific "if" statement.

While this will produce more lines of code, and some may consider it either overkill or unnecessary. I'd suggest that abstracting your scenarios from the specific booleans is the best way to maintain readability.

By splitting things into classes (feel free to just use functions, or whatever other tool you prefer) with understandable names - we can much more easily show the meanings behind each scenario. More importantly, in a system with many moving parts - it is easier to maintain and join into your existing systems (again, despite how much extra code is involed).

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

}

A slight variation on @GianPaolo's fine answer, which some may find easier to read:

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

{

  // ...

}

It depends on what they represent.

For example if 1 is a key, and 2 and 3 are two people who must agree (except if they agree on NOT they need a third person - 4 - to confirm) the most readable might be:

1 &&

    (

        (2 && 3)   

        || 

        ((!2 && !3) && !4)

    )

by popular request:

Key &&

    (

        (Alice && Bob)   

        || 

        ((!Alice && !Bob) && !Charlie)

    )

Every answer is overly complex and difficult to read. The best solution to this is a switch() statement. It is both readable and makes adding/modifying additional cases simple. Compilers are good at optimising switch() statements too.

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;

}

You can of course use constants and OR them together in the case statements for even greater readability.

I am denoting a, b, c, d for clarity, and A, B, C, D for complements

bValue1 = a (!A)

bValue2 = b (!B)

bValue3 = c (!C)

bValue4 = d (!D)

Equation

1 = abcd + abcD + aBCD

  = a (bcd + bcD + BCD)

  = a (bc + BCD)

  = a (bcd + D (b ^C))

Use any equations that suits you.

If (!bValue1 || (bValue2 != bValue3) || (!bValue4 && bValue2))

{

// you have a problem

}

• b1 must always be true


• b2 must always equal b3


• and b4 cannot be false
  if b2 (and b3) are true

simple

Doing bitwise operation looks very clean and understandable.

int bitwise = (bValue4 << 3) | (bValue3 << 2) | (bValue2 << 1) | (bValue1);

if (bitwise == 0b1111 || bitwise == 0b0111 || bitwise == 0b0001)

{

    //satisfying condition

}

First, assuming you can only modify the scenario check, I would focus on readability and just wrap the check in a function so that you can just call if(ScenarioA()).

Now, assuming you actually want/need to optimize this, I would recommend converting the tightly linked Booleans into constant integers, and using bit operators on them

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

}

This makes expressing the scenarios as easy as listing what is part of it, allows you to use a switch statement to jump to the right condition, and confuse fellow developers who have not seen this before. (C# RegexOptions uses this pattern for setting flags, I don't know if there is a c++ library example)

Nested ifs could be easier to read for some people. Here is my 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;

}

My 2 cents: declare a variable sum (integer) so that

if(bValue1)

{

  sum=sum+1;

}

if(bValue2)

{

  sum=sum+2;

}

if(bValue3)

{

  sum=sum+4;

}

if(bValue4)

{

  sum=sum+8;

}

Check sum against the conditions you want and that's it.
This way you can add easily more conditions in the future keeping it quite straightforward to read.

You won't have to worry about invalid combinations of boolean flags if you get rid of the boolean flags.

The acceptable values are:

         Scenario 1 | Scenario 2 | Scenario 3

bValue1: true       | true       | true

bValue2: true       | true       | false

bValue3: true       | true       | false

bValue4: true       | false      | false

You clearly have three states. It'd be better to model that and to derive the boolean properties from those states, not the other way around.

enum State

{

    scenario1,

    scenario2,

    scenario3,

};



bool isValue1(State s)

{

    // (Well, this is kind of silly.  Do you really need this flag?)

    return true;

}



bool isValue2(State s)

{

    switch (s)

    {

        case scenario1:

        case scenario2:

            return true;

        case scenario3:

            return false;

    }

}



bool isValue3(State s)

{

    // (This is silly too.  Do you really need this flag?)

    return isValue2(s);

}



bool isValue4(State s)

{

   switch (s)

    {

        case scenario1:

            return true;

        case scenario2:

        case scenario3:

            return false;

    }

}

If your boolean values can change dynamically, then instead of toggling individual boolean flags (which could result in invalid combinations of flags), you instead can have a state machine that transitions from one scenario to another.

Just a personal preference over the accepted answer, but I would write:

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

A simple approach is finding the answer that you think are acceptable.

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

Now if possible simplify the equation using boolean algebra.

like in this case, acceptable1 and 2 combine to (boolean1 && boolean2 && boolean3).

Hence the final answer is:

(boolean1 && boolean2 && boolean3) || 

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