不能安全重载 && 和 ||，因为会破坏短路求值，导致两侧操作数必然求值，可能引发未定义行为；标准库类型均不重载，应改用显式函数或原生逻辑运算符。
重载 && 和 || 会破坏短路求值
不能安全重载 && 和 ||——这是 C++ 明确不推荐的行为。一旦重载，编译器就无法应用内置的短路求值规则：左侧表达式为真时不再计算右侧，或左侧为假时跳过右侧。重载后两个操作数**必然都会被求值**，可能引发未定义行为、空指针解引用、资源泄漏等。
例如：
if (ptr && ptr->valid()) { ... }
若 ptr 是自定义智能指针并重载了 &&，那么即使 ptr 为空，ptr->valid() 仍会被调用，直接崩溃。
- 短路是语言语义的一部分，不是可选优化
- 重载后的
&&/||实际上变成普通二元函数调用，参数按函数调用规则求值（顺序未指定，且全都要算） - 标准库所有类型（如
std::optional、std::shared_ptr）都**不重载**这两个运算符
替代方案：用显式成员函数或自由函数代替
想表达“逻辑组合”语义，应避免重载运算符，改用清晰命名的函数。比如：
立即学习“C++免费学习笔记（深入）”；
if (a.is_valid() && b.is_ready()) { ... } // 好：语义明确，短路保留
或封装成：
if (both(a, b)) { ... } // 自定义自由函数，内部用原生 <code>&&</code>
-
both()、either()、implies()等函数名比重载&&更易读、更可控 - 若需链式判断（如多个条件），可用
std::all_of或写个简单折叠：conditions | std::ranges::all_of([](auto&& c) { return c(); }) - 切勿为了“看起来像内置语法”而牺牲语义安全和调试友好性
为什么有人还尝试重载？常见误解场景
典型误用是想让自定义布尔类支持类似 if (x && y) 的写法，比如：
struct BoolWrapper { bool value; };
BoolWrapper operator&&(const BoolWrapper& a, const BoolWrapper& b) { return {a.value && b.value}; }
问题在于：
- 这根本没解决“短路”，只是多了一次构造/拷贝开销
- 如果
a或b的构造/转换本身有副作用（如日志、IO、状态变更），副作用必然发生，且顺序不确定 - 和内置
&&行为不一致，团队新人极易踩坑 - 现代 C++ 有
explicit operator bool()，配合原生&&就够用了
唯一合法但危险的例外：代理对象 + 用户自控
极少数场景（如 DSL 构建、表达式模板）确实需要延迟求值，这时不是重载 &&，而是返回一个代理对象：
auto expr = a && b; // 返回 lazy_and<A,B>，不立刻求值
后续显式调用 .eval() 或隐式转换才触发带短路逻辑的手动实现。但这要求：
- 完全绕过内置运算符重载机制
- 用户必须清楚自己在构建表达式树，而非执行逻辑判断
- 所有中间对象生命周期必须严格管理，否则悬垂引用风险极高
这种模式在 boost::spirit 或某些 query 库里存在，但属于高级技巧，99% 的业务代码不该碰。
真正容易被忽略的点是：只要你的类型能隐式转成 bool（或有 explicit operator bool()），原生 && 和 || 就能正常工作且保持短路——你不需要、也不应该重载它们。
