13. The Conditional Operator

Advanced perspective: compact choice without hidden meaning

The conditional operator produces a value

A short expression is not automatically a clear expression. The conditional operator earns its place when one uncomplicated decision supplies one value and the condition, true alternative and false alternative remain visible. Its compact size is only the proxy. The operative criterion is whether a reader can still account for selection, evaluation, result type and use.

The form condition ? second : third has three operands. The first is contextually converted to bool. If it is true, the second operand is selected and evaluated. If it is false, the third operand is selected and evaluated. The whole conditional expression then provides the selected result to its surrounding expression.

An expression can supply a value where a statement cannot

Consider const int larger = a > b ? a : b;. Read it in three parts: ask whether a > b, select a when true, otherwise select b. The result initialises larger. An if statement can control assignments that achieve the same final state, but the statement itself is not a value that can occupy the initializer position.

Translation between the two forms must preserve more than the final printed value. It must preserve which condition is evaluated, which alternative runs, the produced type, every side effect and the point at which those effects occur. Concision is not equivalence evidence.

Trace selection before discussing style

#include <iostream>

int main() {
    const int requestedSpeed{140};
    const int speedLimit{100};
    const int appliedSpeed{requestedSpeed < speedLimit ? requestedSpeed : speedLimit};

    std::cout << appliedSpeed << '\n';
}

Only the selected second or third operand is evaluated. This is selected evaluation, not eager evaluation of all three operands from left to right. If the alternatives call functions, only the selected function is called. If one alternative would dereference a pointer, placing a valid pointer check in the condition can prevent that alternative from being evaluated when the pointer is null.

That property can protect a runtime operation; it cannot make an ill-formed alternative disappear from compilation. In ordinary conditional expressions, both alternatives must participate in determining whether the program is well-formed and what result the expression can have. The unselected alternative is not evaluated at runtime, but it is still source the compiler must understand.

Runtime selection does not choose the result type

The program chooses an alternative at runtime, while the expression has one type determined at compile time. The rule is not "the result has whichever type happened to be selected". Both the second and third operands participate in a sequence of type and value-category rules, including conversions where required.

These examples are useful landmarks, not a replacement for the full C++ rules. Class conversions, references, void, throwing expressions and value categories add cases that slogans cannot safely cover. For introductory code, alternatives of the same clear type make the contract easier to see. If a mixed expression matters, inspect the deduced type and required conversions instead of guessing from the branch taken in one run.

A change from condition ? 0 : 1.5 to condition ? 0.0 : 1.5 may leave the resulting type unchanged while making the intended floating-point choice visible. An explicit cast is not a decoration to silence surprise. Use it only when that conversion is part of the requirement and safe for the values involved.

Selected evaluation and hidden effects must be considered together

Suppose the alternatives are brief ? format_short() : format_long(). Only one formatter is called, which may be exactly the required lazy choice. However, if the calls update counters, write files or modify shared state, the expression also hides an effect behind a value selection. A reader must now verify both the produced value and the effect that did or did not occur.

The operator does not make effects wrong. It makes the cost of understanding them part of the decision about form. When each alternative is a simple value-producing operation with the same responsibility, the expression can be precise. When the alternatives perform different policies, an ordinary if gives those policies enough space to be named and tested.

Grouping is semantic, not cosmetic

The conditional operator associates from right to left. Therefore a ? b : c ? d : e is parsed as a ? b : (c ? d : e). If a is true, b is selected and the nested condition is not evaluated. If a is false, c decides between d and e.

Legal grouping can still be poor communication. Parentheses expose the parse, but they do not turn a compressed classification policy into an easy one. If a nested conditional needs indentation, comments or repeated rereading, the statement form has probably become the smaller explanation.

std::cout << (ok ? "yes" : "no") << '\n';

The parentheses around the conditional result make the intended stream operand explicit. Without them, the surrounding operators and their precedence determine a different grouping from the one a casual reader may imagine. Do not rely on memory of a precedence table when a pair of parentheses can show the structure at the point of use.

A conditional expression can sometimes designate an object

When compatible lvalue alternatives satisfy the relevant rules, the conditional expression can itself be an lvalue. In (chooseLeft ? left : right) = 5;, the condition selects one object and the assignment modifies that object. The operator is not merely choosing a copied integer value in this case; it is selecting the destination.

This can be useful, but it also conceals the mutation target inside punctuation. A named reference can expose the same decision: select left or right into a reference called target, then assign through target. The extra line is worthwhile when the name explains responsibility. Fewer characters are not fewer consequences.

Use equal outputs to expose weak evidence

Run the speed example with requested speeds 80, 100 and 140 while the limit remains 100. Predict the condition result, selected operand and printed value for each case.

That equality case matters. Output of 100 cannot prove which operand was selected because either operand would print 100. Replace each alternative temporarily with a separate value-producing function that records when it is called, then verify that only the false alternative runs at equality. Finally, expand the expression to an if/else initializer strategy and show that selection, type, effects and output remain equivalent. The exercise tests the operator's actual contract, not merely the number it happened to print.

#include <iostream>

int use_requested_speed(int value) {
    std::cout << "requested speed selected\n";
    return value;
}

int use_speed_limit(int value) {
    std::cout << "speed limit selected\n";
    return value;
}

int main() {
    const int requestedSpeed{100};
    const int speedLimit{100};
    const int appliedSpeed{
        requestedSpeed < speedLimit
            ? use_requested_speed(requestedSpeed)
            : use_speed_limit(speedLimit)
    };

    std::cout << appliedSpeed << '\n';
}

int choose_speed(int requestedSpeed, int speedLimit) {
    if (requestedSpeed < speedLimit) {
        return use_requested_speed(requestedSpeed);
    } else {
        return use_speed_limit(speedLimit);
    }
}

int main() {
    const int requestedSpeed{100};
    const int speedLimit{100};
    const int appliedSpeed{choose_speed(requestedSpeed, speedLimit)};

    std::cout << appliedSpeed << '\n';
}