枚举依赖于整数布尔转换

Question

在我的编译器项目中，我有一个类似于

的枚举

enum Result {
  No,
  Maybe,
  Yes
};

我已将No显式放在第一个位置，以便我可以依赖布尔评估false。如果我的编译器不确定某些东西，并且必须等到事实直到运行时，它的分析函数将返回Maybe。像

一样使用

if(!typesEqual(t1, t2)) {
  diagnose(types_unequal) << t1 << t2;
}

我想知道您或您的公司是否认为不能明确地与No进行比较

if(typesEqual(t1, t2) == No) { /* ... */ }

明确地比较对我来说似乎很啰嗦，但依赖于隐式布尔转换会让我感到内疚。你以前有这种感觉，你是如何处理的？

Answer 1

我也感到内疚，因为从阅读上面的代码你期望布尔typesEqual()表达式为Maybe返回什么？它会回归真的吗？也许！它会返回虚假吗？也许！我们不知道 - 这就是枚举的全部内容。这就是明确与No进行比较有意义的原因，即使它更详细。

Answer 2

我通常不会对积分或指针类型使用零进行显式比较，因为转换为布尔值是明确定义的并且很明显。

但是，我总是使用枚举的显式比较，以防万一某人更改了枚举的定义。毕竟，你永远不能确定有人不会改变枚举。

依赖于枚举器的基础数值似乎是一个坏主意。

Answer 3

这似乎与Boost.Tribool类似。 Tribool支持转换为bool以用于条件语句，这似乎表明在这种情况下隐式转换为bool并不坏，至少根据Boost组织（我发现它是相当合理的）。 / p>

Answer 4

我不喜欢它是不对称的。

E.g。你真正想要的地方是

if(typesEqual(t1, t2) == Yes) {
    do_something();
}

但偶然你写了

if(typesEqual(t1, t2)) {
    do_something();
}

似乎有些奇怪/丑陋，你可以使用布尔技巧来表示否，但不能用于是。

我想我会通过将函数重命名为tryCompareTypes(t1, t2)并将您的枚举更改为

来解决此问题

enum Result {
  Maybe,
  No,
  Yes
};

所以tryCompareTypes()如果“失败”确定类型是否相等则返回0，否则返回No或Yes，两者都非零，因此表示“成功”。