问题标签 [safe-bool-idiom]

有人可以解释一下为什么这段代码：

产生以下编译器错误？

由于两个safe_bool模板都派生自safe_bool_base，我不明白为什么不能访问基类的受保护成员。

我错过了什么吗？

Hey guys, I have derived my class from the C++ safe bool idiom class from this page : The Safe Bool Idiom by Bjorn Karlsson

When I tried to use it in the if expression like below

I got an error C2451: conditional expression of type 'Element' is illegal. If I try to cast it to bool like below, I got this error

error C2440: 'type cast' : cannot convert from 'Element' to 'bool'

This is the 1st time I am using safe bool idiom, I am not sure if this is not allowed or a bug in Visual C++ 10. Any comments? Thanks in advance!

@R的这个答案。Martinho Fernandes表明，safe-bool 习惯用法在 C++11 中显然已被弃用，因为它可以被一个简单的替换

根据答案中的标准报价§4 [conv] p3：

对于某些发明的临时变量（第 8.5 节） ，T当且仅当声明格式正确时，表达式 e 才能隐式转换为类型。某些语言结构要求将表达式转换为布尔值。对于某些发明的临时变量 t（第 8.5 节），当且仅当声明格式正确时，出现在这种上下文中的表达式被称为上下文转换为格式正确。T t=e;teboolbool t(e);

突出显示的部分清楚地将“隐式显式转换”（在标准中称为“上下文转换”）显示为@R。马蒂尼奥说的。

需要“隐式显式转换”的“某些语言结构”似乎如下：

• if, while, for( §6.4 [stmt.select] p4)
• 二元逻辑运算符&&and ||(§5.14 [expr.log.and/or] p1对于两者)
• 逻辑否定运算符!( §5.3.1 [expr.unary.op] p9)
• 条件运算符?:( §5.14 [expr.cond] p1)
• static_assert( §7 [dcl.dcl] p4)
• noexcept( §15.4 [except.spec] p2)

我们在标题中的假设是否正确？我希望我们没有忽略任何潜在的缺点。

25% 的程序员工作时间花在检查所需代码是否已经存在上。

我正在寻找一个实现安全布尔成语的基类。

考虑以下安全布尔成语的摘录：

是否可以在没有 typedef 的情况下声明转换函数？以下不编译：

我有另一个与安全布尔成语有关的问题：

bool_type（typedef）和this_type_does_not_support_comparisons是怎么来的const？无论如何，没有人应该通过返回指针实际调用成员函数，对吧？这里有const必要吗？operator bool_type否则（成员函数）会违反 const 正确性吗？

来自@Xeo 的优秀c++-faq问题：安全布尔成语在 C++11 中是否已过时？我了解到不再需要安全布尔惯用语，因为在 C++03 中需要安全布尔的上下文中，将自动调用explicit用户定义的转换为。bool

&&但是，重载,||和等运算符的能力!似乎可以规避这一点。

operator!除了提供转换之外必要的情况bool很少见，例如operator&&and operator||，但是 C++ 表达式树实现（用于延迟执行和符号数学技术）确实需要覆盖这些。

调用用户定义的运算符时是否发生“上下文转换”？需要什么样的 SFINAE 咒语来确保定义operator&&或operator||将与实现“安全布尔”的类型和为“上下文转换”设计的类型正确工作？

为了澄清，给定：

需要哪些签名才能operator||使以下表达式均有效：

这些使用不同的重载：

并且在编译时拒绝以下内容：

我被指出“安全布尔成语”，在试图破译发生了什么之后（网站上提供的解释不足以让我理解它的工作原理），我决定尝试采用以下代码分开并尝试尽可能地简化它。该网站提供的代码如下：

我决定分析'bool_type'的关键基础，因为这似乎是它的中心。鉴于以下行：

可以（由于括号而不那么容易）推断出它是一种类型为 'void Testable::*' 的 typedef，其中 bool_type 表示。这可以通过进行以下修改和函数调用来进一步证明：

它允许我们查看 bool_type 是什么类型：

错误：无法在初始化中将 'void (Testable::*)()const' 转换为 'int'

这表明它确实是一种“void (Testable::*)”。

问题出现在这里：

如果我们修改以下函数：

并将其变成：

它会产生以下投诉：

错误：“*”标记之前的预期标识符
错误：“<无效运算符>”声明为返回函数的函数

我的问题是：

如果 'void (Testable::*) 确实是 bool_type 的 typedef，为什么会产生这些抱怨？

和

这里发生了什么？

我正在考虑用explicit operator bool已经使用 C++11 功能的代码替换所有安全布尔成语的实例（所以旧编译器不识别显式转换运算符的事实并不重要），所以我想知道如果它会导致一些微妙的问题。

因此，从旧的和沉闷的安全 bool 成语切换到新的和闪亮的，可能导致的所有explicit operator bool可能的不兼容（即使是最微小的不兼容）是什么？

编辑：无论如何，我知道切换是一个好主意，因为后者是一种语言功能，编译器很好理解，所以它的工作不会比实际上只是一个 hack 更糟糕。我只是想知道可能的差异。

我正在尝试利用boost::bool_testable<>（来自 Boost.Operators）为一个类实现安全的 bool 习惯用法，但该库的最新版本（截至本文为 1.49）似乎不再具有它。

它去哪儿了？现在有没有更好的替代品，而我只是错过了它？

我不能使用 C++11，因此不能使用不需要安全布尔的语言扩展。