ChatGPT解决这个技术问题 Extra ChatGPT

How to improve logic to check whether 4 boolean values match some cases

I have four bool values:

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

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

So, for example, this scenario is not acceptable:

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

At the moment I have come up with this if statement to detect bad scenarios:

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

Can that statement logic be improved/simplified?

I would use a table instead of complex if statement. Additionally, as these are boolean flags, you can model each scenario as a constant and check against it.
if (!((bValue1 && bValue2 && bValue3) || (bValue1 && !bValue2 && !bValue3 && !bValue4)))
what are the scenarios actually? Often things get much simpler if you just give stuff proper names, eg bool scenario1 = bValue1 && bValue2 && bValue3 && bValue4;
Using meaningful names, you can extract each complex condition into a method and call that method in if condition. It would be much more readable and maintainable. e.g. Take a look at the example provided in the link.refactoring.guru/decompose-conditional

G
Gian Paolo

I would aim for readability: you have just 3 scenario, deal with them with 3 separate 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

Easy to read and debug, IMHO. Also, you can assign a variable whichScenario while proceeding with the if.

With just 3 scenarios, I would not go with something such "if the first 3 values are true I can avoid check the forth value": it's going to make your code harder to read and maintain.

Not an elegant solution maybe surely, but in this case is ok: easy and readable.

If your logic gets more complicated, throw away that code and consider using something more to store different available scenarios (as Zladeck is suggesting).

I really love the first suggestion given in this answer: easy to read, not error prone, maintainable

(Almost) off topic:

I don't write lot of answers here at StackOverflow. It's really funny that the above accepted answer is by far the most appreciated answer in my history (never had more than 5-10 upvotes before I think) while 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 :)


sure @hessamhedieh, it's ok only for a small number of available scenario. as I said, if things get more complicated, better look for something else
This can be simplified further by stacking all conditions into the initializer for valid and separating them with ||, rather than mutating valid within separate statement blocks. I can't put an example in the comment but you can vertically align the || operators along the left to make this very clear; the individual conditions are already parenthesized as much as they need to be (for if) so you don't need to add any characters to the expressions beyond what is already there.
@Leushenko, I think that mixing parenthesis, && and || conditions is quite error prone (someone in a different answer said there was an error in parenthesis in the code in OP, maybe it has been corrected). Proper alignment can help, sure. But what is the advantage? more readable? easier to maintain? I don't think so. Just my opinion, of course. An be sure, I really hate having lot of ifs in code.
I'd've wrapped it in a if($bValue1) as that always has to be true, technically allowing some minor performance improvement (though we're talking about negligable amounts here).
FWIW: there are only 2 scenarios: the first 2 are the same scenario and do not depend on bValue4
A
Anders

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


+1 This is what I would have done as well. Just like @RedFilter points out, and in contrast to the accepted answer, this is self-documenting. Giving the scenarios their own names in a separate step is much more readable.
P
P.W

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.

https://i.stack.imgur.com/wlO2Q.png

This yields:

https://i.stack.imgur.com/HNAvs.png

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.


Though technically correct, this code requires a lot of comments in order to be edited by another developer few months later.
@ZdeslavVojkovic: I would just add a comment with the equation. //!(ABC + AB'C'D') (By K-Map logic). That would be a good time for the developer to learn K-Maps if he doesn't already know them.
I agree with that, but IMO the problem is that it doesn't map clearly to the problem domain, i.e. how each condition maps to specific scenario which makes it hard to change/extend. What happens when there are E and F conditions and 4 new scenarios? How long it takes to update this if statement correctly? How does code review check if it is ok or not? The problem is not with the technical side but with "business" side.
I think you can factor out A: ABC + AB'C'D' = A(BC + B'C'D') (this can be even factored to A(B ^ C)'(C + D') though I'd be careful with calling this 'simplification').
@P.W That comment seems about as understandable as the code, and is thus a bit pointless. A better comment would explain how you actually came up with that equation, i.e. that the statement should trigger for TTTT, TTTF and TFFF. At that point you might as well just write those three conditions in the code instead and not need an explanation at all.
A
Andrew Truckle

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

Not the most maintainable but definitely simplifies the if condition. So leaving a few comments around the bitwise operations will be an absolute necessity here imo.
IMO, table is the best approach as it scales better with additional scenarios and flags.
I like your first solution, easy to read and open to modification. I would make 2 improvements: 1: assign values to scenarioX with an explicit indication of boolean values used, e.g. SCENARIO_2 = true << 3 | true << 2 | true << 1 | false; 2: avoid SCENARIO_X variables and then store all available scenarios in a <std::set<int>. Adding a scenario is going to be just something as mySet.insert( true << 3 | false << 2 | true << 1 | false; maybe a little overkill for just 3 scenario, OP accepted the quick, dirty and easy solution I suggested in my answer.
If you're using C++14 or higher, I'd suggest instead using binary literals for the first solution - 0b1111, 0b1110 and 0b1000 is much clearer. You can probably also simplify this a bit using the standard library (std::find?).
I find that binary literals here would be a minimal requirement to make the first code clean. In its current form it’s completely cryptic. Descriptive identifiers might help but I’m not even sure about that. In fact, the bit operations to produce the scenario value strike me as unnecessarily error-prone.
G
Gian Paolo

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.


You know you can always edit your previous answer and make improvements.
S
Stack Danny

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

I love this approach, except for the main function’s name: “from bool … to what?” — Why not explicitly, bitmap_from_bools, or bools_to_bitmap?
yes @KonradRudolph, I couldn't think of a better name, except maybe bools_to_unsigned. Bitmap is a good keyword; edited.
I think you want summary!= 0b1111u &&.... a != b || a != c is always true if b != c
A
Andreas

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

Yes, but hard to understand. But thanks for suggestion.
I compared compilers ability to simplify expression with your simplification as a reference: compiler explorer. gcc did not find your optimal version but its solution is still good. Clang and MSVC don't seem to perform any boolean expression simplification.
@AndrewTruckle: note, that if you needed a more readable version, then please say so. You've said "simplified", yet you accept an even more verbose version than your original one.
simple is indeed a vague term. Many people understand it in this context as simpler for developer to understand and not for the compiler to generate code, so more verbose can indeed be simpler.
@IsmaelMiguel: when a logic formula is optimized for number of terms, the original meaning is usually lost. But one can put a comment around it, so it is clear what it does. Even, for the accepted answer, a comment would not harm.
Y
Yakk - Adam Nevraumont

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.


The first version is so easy to read and so maintenable, I really like it. The second one is harder to read, at least for me, and requires a c++ skill level maybe over the average, surely over my one. Not something everyone is able to write. Just learned somethin new, thanks
A
Andrew Truckle

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.


Thanks for sharing the solution. :) It's actually better than the complex if conditions hell. Maybe you can still name INCLUDE_ITEM1 etc in a better way and you are all good. :)
@HardikModha Well, technically they are "Student items" and the flag is to indicate if they are to be "included". So I think the name, albeit sounding generic, is actually meaningful in this context. :)
A
Andrew Truckle

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 like this slightly more than Gian Paolo's (already nice) solution: It avoids control flow and the use of a variable that is overwritten - more functional style.
h
hessam hedieh

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.


I'm pretty sure this is wrong, though. It assumes that the compiler uses only a single binary representation for true. A compiler which uses "anything non-zero is true" causes this code to fail. Note that true must convert to 1, it just doesn't need to be stored as such.
@MSalters, tnx, I get your point and I am aware of that, kinda like 2 is not equal to true but evaluates to true, my code doesnt force int 1 = true and works as long as all true's are converted to same int value, SO here is my question: Why compiler should act random on converting true to underlying int, Can you please elaborate more?
Performing a memcmp to test boolean conditions is not the C++ way, and I rather doubt that it’s an established C way, either.
@hessamhedieh: The problem in your logic is "converting true to underlying int". That is not how compilers work,
Your code increases complexity from O(1) to O(n). Not a way to go in any languages - leave aside C/C++.
M
Michał Łoś

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.


g
gsamaras

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.


M
Matt

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

s
shogged

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.


Being an old C-programmer, I'd define a "PackBools" macro and use that both for the "switch(PackBools(a,b,c,d))" and for the cases, eg either directly "case PackBools(true, true...)" or define them as local constants.e.g. "const unsigned int scenario1 = PackBools(true, true...);"
G
Gnudiff

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.


佚名

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

At some point, verbosity starts to harm readability. I think this goes too far.
@JollyJoker I do actually agree in this specific situation - however, my gut feeling from the way OP has named everything extremely generically, is that their "real" code is likely a lot more complex than the example they've given. Really, I just wanted to put this alternative out there, as it's how I'd structure it for something far more complex/involved. But you're right - for OPs specific example, it is overly verbose and makes matters worse.
i
ispiro

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

You might be right, but using numbers to illustrate your point detracts from your answer. Try using descriptive names.
@jxh Those are the numbers OP used. I just removed the bValue.
@jxh I hope it's better now.
D
Derviş Kayımbaşıoğlu

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
}

The bitwise comparison looks readable to me. The composition, on the other hand, looks artificial.
m
mesibo

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.


O
Owen Meyer
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


F
François Gueguen

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

T
Tezra

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)


In actual fact I am not using four bool values but a DWORD with four embedded BOOLS. Too late to change it now. But thanks for your suggestion.
s
sardok

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

Personally, I'd usually avoid nesting if statements if possible. While this case is nice and readable, once new possibilities are added, the nesting can become very hard to read. But if the scenarios never change, it definitly is a nice and readable solution.
@Dnomyar96 i agree. I personally avoid nested ifs too. Sometimes if the logic is complicated, it is easier for me to understand the logic by breaking it down into the pieces. For example, once you enter bValue1 block, then you may treat everything in it as a new fresh page in your mental process. I bet the way of approaching to the problem may be very personal or even cultural thing.
f
fralau

Several correct answers have been given to this question, but I would take a different view: if the code looks too complicated, something isn't quite right. The code will be difficult to debug and more likely to be "one-use-only".

In real life, when we find a situation like this:

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

When four states are connected by such a precise pattern, we are dealing with the configuration of some "entity" in our model.

An extreme metaphor is how we would describe a "human beings" in a model, if we were not aware of their existence as unitary entities with components connected into specific degrees of freedom: we would have to describe independent states of of "torsoes", "arms", "legs" and "head" which would make it complicated to make sense of the system described. An immediate result would be unnaturally complicated boolean expressions.

Obviously, the way to reduce complexity is abstraction and a tool of choice in c++ is the object paradigm.

So the question is: why is there such a pattern? What is this and what does it represent?

Since we don't know the answer, we can fall back on a mathematical abstraction: the array: we have three scenarios, each of which is now an array.

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

At which point you have your initial configuration. as an array. E.g. std::array has an equality operator:

At which point your syntax becomes:

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

}

Just as the answer by Gian Paolo, it short, clear and easily verifiable/debuggable. In this case, we have delegated the details of the boolean expressions to the compiler.


j
jamesdlin

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 (scenarios). 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,
};

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

This is definitely more code than in Gian Paolo's answer, but depending on your situation, this could be much more maintainable:

There is a central set of functions to modify if additional boolean properties or scenarios are added. Adding properties requires adding only a single function. If adding a scenario, enabling compiler warnings about unhandled enum cases in switch statements will catch property-getters that don't handle that scenario.

Adding properties requires adding only a single function.

If adding a scenario, enabling compiler warnings about unhandled enum cases in switch statements will catch property-getters that don't handle that scenario.

If you need to modify the boolean properties dynamically, you don't need to re-validate their combinations everywhere. Instead of toggling individual boolean flags (which could result in invalid combinations of flags), you instead would have a state machine that transitions from one scenario to another.

This approach also has the side benefit of being very efficient.


J
Jim Cullen

The accepted answer is fine when you've only got 3 cases, and where the logic for each is simple.

But if the logic for each case were more complicated, or there are many more cases, a far better option is to use the chain-of-responsibility design pattern.

You create a BaseValidator which contains a reference to a BaseValidator and a method to validate and a method to call the validation on the referenced validator.

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

Then you create a number of subclasses which inherit from the BaseValidator, overriding the validate method with the logic necessary for each validator.

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

Then using it is simple, instantiate each of your validators, and set each of them to be the root of the others:

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

In essence, each validation case has its own class which is responsible for (a) determining if the validation matches that case, and (b) sending the validation to someone else in the chain if it is not.

Please note that I am not familiar with C++. I've tried to match the syntax from some examples I found online, but if this does not work, treat it more like pseudocode. I also have a complete working Python example below that can be used as a basis if preferred.

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

Again, you may find this overkill for your specific example, but it creates much cleaner code if you end up with a far more complicated set of cases that need to be met.


K
Kobap Bopy
if(!bValue1)
    return false;
if(bValue2 != bValue3)
    return false;
if(bValue3 == false && bValuer4 == true)
    return false;
return true;

A
Andrew Truckle

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.


h
hedzr

use bit field:

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:

That's a big pity to CPPers'. But, UB is not my worry, check it at http://coliru.stacked-crooked.com/a/2b556abfc28574a1.


This causes UB due to accessing an inactive union field.
Formally it's UB in C++, you can't set one member of union and read from another. Technically it might be better to implement templated getters\setters for bits of integral value.
I think the behavior would shift to Implementation-Defined if one were to convert the union's address to an unsigned char*, though I think simply using something like ((((flag4 <<1) | flag3) << 1) | flag2) << 1) | flag1 would probably be more efficient.