Is overloading logical operations a good or bad practice?

Overloading logical operators (&&, ||, !) in C++ can be both useful and dangerous.

Possible advantages:

• More readable code: In some specialized fields, such as algebraic or logical systems, overloading can make expressions more intuitive.

Possible disadvantages:

• Loss of short-circuiting rule: Standard logical operators in C++ evaluate the second operand only if necessary. Overloaded operators implemented as functions will always evaluate both operands before the function call. This can lead to performance issues or side effects.
• Unexpected behavior: Users of your class might expect the standard behavior of logical operators, which can be broken by overloading.
• Debugging difficulties: Debugging expressions with overloaded operators can be more complex due to the loss of short-circuiting semantics.

Example of losing short-circuiting:

#include <iostream>

struct MyBool {
    bool value;

    MyBool operator&&(const MyBool& other) const {
        std::cout << "Evaluating && (both operands evaluated)" << std::endl;
        return MyBool {value && other.value};
    }

    // For demonstrating side effects
    bool getValue() const {
        std::cout << "Evaluating getValue()" << std::endl;
        return value;
    }
};

int main() {
    MyBool a {false};
    MyBool b {true};

    // In standard short-circuiting, a.getValue() will be called,
    // but b.getValue() will not if a.getValue() is false.
    // With overloaded operator, both getValue() can be called.
    if (a.getValue() && b.getValue()) {
        // ...
    }

    MyBool result = a && b; // Call to overloaded operator &&
    return 0;
}

Conclusion:

In most everyday cases, it is strongly recommended to avoid overloading logical operators (&&, ||). The risks of losing expected behavior and short-circuiting often outweigh potential benefits. If logical behavior is needed for a user-defined type, it is preferable to implement it through named methods (e.g., and_, or_) or explicitly call methods returning boolean values. Overloading the ! (logical NOT) operator is less risky, as it is unary and does not involve short-circuiting issues.

In very specific, well-isolated application domains with clear documentation of behavior, overloading may be permissible but requires extreme caution.