Compound Boolean Conditions - C Plus Plus

1. Which while condition correctly expresses the continuation rule?
   Answer: (itemsRemaining > 0 || retryPending) && !shutdown && failures < maxFailures When translating a word problem into a Boolean condition, your job is to map each logical clause precisely — "continue while X or Y, but stop if P or Q" becomes (X || Y) && !P && !Q. The stopping conditions must both be absent for the loop to run, which means they're joined with && after negation. The passage gives you two continuation triggers (items remaining or retry pending) and two stopping triggers (shutdown is true or failures hit the max). Correctly expressed: the loop continues when (itemsRemaining > 0 || retryPending) is satisfied, and shutdown is false, and failures < maxFailures. That's exactly what D gives you — a clean separation between the "keep going" side and the "must stop" side. Answer A is tempting but wrong: (!shutdown || failures < maxFailures) means the loop continues even during shutdown as long as failures haven't maxed out. That's not a hard stop on shutdown — it lets shutdown be overridden, which breaks the rule. Answer B incorrectly restricts the retry-pending check. It only applies !shutdown && failures < maxFailures to retryPending, leaving itemsRemaining > 0 unchecked against the stopping conditions. A loop could run indefinitely despite a shutdown if items remain. Answer C uses && between itemsRemaining > 0 and retryPending, meaning both must be true to continue — that contradicts the "either/or" continuation rule. It also uses <= instead of < for maxFailures, allowing one extra failure through. As a strategy: always translate stop-conditions into negated && guards. If the problem says "stop when X," write && !X. Mixing || into stop conditions is the classic trap this question is testing.
2. Which C++ condition is true exactly for leap years?
   Answer: year % 4 == 0 && (year % 100 != 0 || year % 400 == 0) When translating a multi-part rule into a Boolean expression, your job is to map each clause of the rule to a logical operator — and the Gregorian leap year rule has a specific structure worth unpacking carefully. The rule says: divisible by 4, except divisible by 100, unless also divisible by 400. Break it into two cases that qualify as a leap year: (1) divisible by 4 but not by 100, or (2) divisible by 400 (which implies divisibility by both 100 and 4). Combining these: year % 4 == 0 must hold, and then either year % 100 != 0 or year % 400 == 0. That gives you D: year % 4 == 0 && (year % 100 != 0 || year % 400 == 0). Test it on 2000 (divisible by 400 → leap ✓), 1900 (divisible by 100 but not 400 → not leap ✓), and 2024 (divisible by 4, not 100 → leap ✓). A is self-contradictory — it requires year % 100 != 0 AND year % 400 == 0 simultaneously, but any year divisible by 400 is also divisible by 100, so this condition can never be true. B flips the logic inside the parentheses: year % 100 == 0 || year % 400 != 0 incorrectly includes century years that aren't divisible by 400 (like 1900). C uses || at the top level instead of &&, making years like 1900 (divisible by 4 via the first clause alone) incorrectly qualify. A useful tip: when a rule says "X except Y unless Z," always write it out in plain English cases first, then convert to Boolean — this prevents operator mistakes under pressure.
3. Which C++ condition is the exact logical negation of the access condition?
   Answer: role != "admin" && (!active || !verified) When you need to negate a logical expression in C++, your go-to tool is De Morgan's Laws: - NOT (A || B) becomes (!A && !B) - NOT (A && B) becomes (!A || !B) The original access condition is role == "admin" || (active && verified). To find who is denied access, you negate the entire expression. Start by applying the first law to the outer OR: !(role == "admin") && !(active && verified) This simplifies to role != "admin" for the first part. Then apply the second law to negate the inner AND: role != "admin" && (!active || !verified) That's exactly answer A — the correct negation. Notice the outer operator flips from || to &&, and the inner && flips to ||. B is wrong because it uses || as the outer operator instead of &&. Flipping the OR to another OR isn't negation — the outer operator must change. C makes two mistakes: it keeps && on the outside (correct) but uses && inside as well, negating the inner AND incorrectly — it should become ||, not stay &&. D uses || as the outer operator (already wrong, like B) and also incorrectly applies || inside, compounding the error. A useful memory trick: when negating, everything flips — || becomes && and vice versa, and each individual condition negates. If you only flip one thing and not the other, you'll land on one of these distractors every time.
4. Which condition correctly enforces the intended rules?
   Answer: (ready && retries < 3 || overrideMode) && !locked When translating a word problem into a boolean expression, your first job is to identify the grouping structure — which conditions belong together, and what applies universally. Here, the passage gives you two paths to start the process, but one constraint that always applies: locked must be false, no exceptions. The two valid start conditions are: (1) ready && retries < 3, or (2) overrideMode. These form a natural OR group: (ready && retries < 3 || overrideMode). Then, since !locked applies to both paths regardless, it gets ANDed onto the entire group. That gives you B: (ready && retries < 3 || overrideMode) && !locked — which correctly enforces all three rules. Looking at the wrong answers: A is the classic operator-precedence trap. Without parentheses around the OR, C++ evaluates && before ||, so it reads as (ready && retries < 3) || (overrideMode && !locked). This lets the process start via the first path even when locked, violating the core constraint. C misreads the structure — it requires ready in all cases, meaning overrideMode alone can never start the process without ready also being true. That defeats the purpose of override mode entirely. D similarly misreads the logic by requiring retries < 3 in all cases, including when overrideMode is active — again defeating override mode's intent. As a study tip: whenever !locked (or any "universal" condition) appears, ask yourself — does this apply to every path? If yes, it must be ANDed outside all the OR groupings, not buried inside one branch.
5. Which condition safely and correctly performs the test using short-circuit evaluation?
   Answer: i >= 0 && static_cast<std::size_t>(i) < values.size() && values[i] != 0 && target / values[i] > 2 When evaluating compound conditions in C++, the && operator short-circuits: if any subexpression evaluates to false, the remaining subexpressions are skipped entirely. This makes ordering critical whenever later checks depend on earlier ones being true. Here, you have three safety dependencies to respect: first confirm i is non-negative, then confirm it's a valid index into values, then confirm values[i] is nonzero before dividing by it. Option C chains these guards in exactly that order — i >= 0, then the bounds check, then values[i] != 0, and finally the division. Each check protects the next, so no undefined behavior can occur. Option A fails because it accesses values[i] (checking != 0) before verifying the index is within bounds. If i is out of range, that access is undefined behavior regardless of whether division is reached. Option B checks bounds correctly but then immediately divides target / values[i] before confirming values[i] != 0 — a potential division-by-zero. Option D introduces a logical error with || inside the last clause: (values[i] != 0 || target / values[i] > 2) would only skip the division when values[i] != 0 is true, but when values[i] is zero, the || evaluates the right side — which divides by zero anyway. The key strategy: when writing guard conditions, always ask "does this subexpression depend on the previous one being safe?" If yes, the dependency must come first. Think of it as building a sequence of locked doors — you can't open door two until door one is confirmed open.
6. Which C++ condition correctly implements all of the registration requirements?
   Answer: age >= 18 && age <= 65 && (member || guestPass) && !suspended When translating a word problem into a C++ boolean expression, your job is to map each logical requirement to the correct operator: && for "and" (all conditions must hold), || for "or" (at least one must hold), and ! for "not." Break the passage into individual rules first, then combine them. The passage gives you four requirements: (1) age is between 18 and 65 inclusive, (2) the applicant is a member or has a guest pass, (3) the applicant is not suspended. "Inclusive" means both endpoints count, so you need >= and <=, not strict inequalities. All three requirements must be satisfied simultaneously, so they connect with &&. The member/guest-pass clause uses || since either one suffices, and it must be parenthesized so it's evaluated as a unit before being &&-ed with the rest. That gives you exactly answer A: age >= 18 && age <= 65 && (member || guestPass) && !suspended. Answer B incorrectly groups age <= 65 || member together, meaning a member of any age would satisfy that portion — that's not what the problem states. It also requires guestPass to always be true rather than treating it as an alternative to member. Answer C uses a top-level ||, meaning registration could be accepted by only satisfying age+member or only guestPass+notSuspended — neither path enforces all rules. Answer D uses strict inequalities (> and <), excluding the endpoints 18 and 65, which violates the "inclusive" requirement. A useful habit: underline the words "and," "or," "not," and "inclusive/exclusive" in the problem before writing a single character of code — those words map directly to &&, ||, !, and your choice of <= vs. <.
7. Which condition correctly determines whether the alarm should activate?
   Answer: armed && !maintenance && (sensorA != sensorB) When a problem asks for "exactly one of two conditions to be true," that's the classic definition of XOR (exclusive OR). In C++, you can express XOR between two Boolean values using the != operator — because two Booleans are "not equal" only when one is true and the other is false. For the alarm to trigger, three things must all hold: the system is armed, maintenance mode is off, and exactly one sensor is active. This translates directly to armed && !maintenance && (sensorA != sensorB), making C the correct answer. When sensorA and sensorB differ (one true, one false), != returns true. When both are true or both are false, it returns false — exactly the behavior you need. A uses sensorA == sensorB, which activates the alarm when both sensors match — either both on or both off. That's the opposite of what you want; it's XNOR, not XOR. B uses sensorA || sensorB, which triggers whenever at least one sensor is active. This incorrectly includes the case where both sensors fire simultaneously, violating the "exactly one" requirement. D has a precedence and logic error — the parentheses group !maintenance || sensorA != sensorB, meaning the system doesn't need to be in maintenance-off mode if sensorA != sensorB is true. This breaks the requirement that all three conditions must hold independently. As a study tip: whenever you see "exactly one of two" in a problem, immediately think != for Booleans — it's C++'s built-in XOR.
8. Which C++ condition should determine whether the surcharge applies?
   Answer: (weight < 5 || weight > 20 || remote) && !employeeWaiver When translating business rules into boolean logic, your job is to identify two things: what triggers the condition, and what cancels it entirely. Here, the surcharge is triggered by any of three factors — low weight, high weight, or remote destination — but the employee waiver completely overrides all of them, regardless of cause. That "regardless of" language is your signal that the waiver must be applied outside and after the entire trigger group. The correct structure is: (any trigger) AND NOT waiver. Answer A — (weight < 5 || weight > 20 || remote) && !employeeWaiver — does exactly this. The parentheses group all three triggers with OR, then the waiver blocks the surcharge universally via AND. B is a subtle but critical error: it only applies !employeeWaiver to the remote condition, meaning a package that's under 5 kg would still be surcharged even with a waiver. The waiver's scope is too narrow. C uses <= and >= instead of < and >, changing the boundary thresholds. A package weighing exactly 5 kg or exactly 20 kg would incorrectly trigger the surcharge. Always match the strict inequalities to the stated rules ("less than 5," "more than 20"). D logically collapses because weight < 5 && weight > 20 can never be true simultaneously — no package can weigh both less than 5 and more than 20 kg at once, so the weight conditions would never fire. As a study tip: when a waiver or override "applies regardless" of other conditions, it must wrap the entire trigger expression — not just one branch of it.
9. Which condition implements the input rule correctly?
   Answer: !blocked && ((c >= '1' && c <= '9') || (c >= 'A' && c <= 'F')) When combining logical conditions in C++, operator precedence determines how expressions group — and && binds more tightly than ||. Forgetting this is one of the most common sources of subtle bugs, and this question tests exactly that. The rule requires both conditions to hold: blocked must be false, and c must fall in one of the two valid ranges. Answer B correctly captures this by wrapping the entire character-range check in its own parentheses: !blocked && ((c >= '1' && c <= '9') || (c >= 'A' && c <= 'F')). This ensures !blocked applies to the whole range expression, and the || correctly joins the two alternatives. Answer A is the classic precedence trap. Without the outer parentheses, && binds first, so the expression parses as (!blocked && (c >= '1' && c <= '9')) || (c >= 'A' && c <= 'F'). This means a character like 'B' would be accepted even when blocked is true — completely breaking the blocking logic. Answer C uses strict inequality (> and < instead of >= and <=), which excludes the boundary characters '1', '9', 'A', and 'F' themselves. The endpoints are valid inputs, so this silently rejects characters it should accept. Answer D confuses && and || within the range checks. Writing c >= '1' || c <= '9' is nearly always true for any character, making the condition far too permissive and logically meaningless as a range guard. As a rule of thumb: whenever you combine && and || in one expression, use parentheses explicitly to enforce your intended grouping — never rely on precedence alone.
10. Which C++ condition correctly identifies an unusual reading?
    Answer: temperature >= 10 && temperature < 30 && (pressure < 90 || pressure > 110) When translating a word problem into C++ conditions, you need to map each boundary word carefully — "at least" means >=, "below" means <, and "outside an inclusive interval" means the value is either too low or too high using strict inequalities. The passage requires two things simultaneously: temperature is at least 10 (>= 10) and below 30 (< 30), while pressure is outside the inclusive range [90, 110], meaning it's either less than 90 or greater than 110. Answer B captures this exactly: temperature >= 10 && temperature < 30 && (pressure < 90 || pressure > 110). Each boundary is correctly translated and the two pressure cases are grouped with || inside parentheses, then joined to the temperature check with &&. A is wrong because C++ does not support chained comparisons like 10 <= temperature < 30. The compiler evaluates 10 <= temperature as a boolean (0 or 1), then compares that result to 30, which always evaluates to true — not what you intend. C uses the wrong boundary operators: temperature > 10 excludes the value 10 itself (but "at least 10" should include it), and temperature <= 30 wrongly includes 30 (but "below 30" excludes it). The pressure condition also incorrectly uses <= and >=, which would include the safe boundary values. D correctly handles temperature but breaks the pressure logic. A single value can never be both less than 90 and greater than 110 at the same time, so pressure < 90 && pressure > 110 is always false. As a general strategy, always check whether each boundary is inclusive or exclusive, and remember that C++ does not support chained comparisons — each condition must be written out separately.

Start this quiz