Является ли идиома Safe-Bool устаревшей в C ++ 11?

Question

Это ответ @R.Мартиньо Фернандес показывает, что идиома safe-bool в C ++ 11 практически не рекомендуется, поскольку ее можно заменить простой

explicit operator bool() const;

в соответствии со стандартной цитатой в ответе §4 [conv] p3:

Выражение e может быть неявно преобразовано в тип T тогда и только тогда, когда объявление T t=e; правильно сформировано для некоторой изобретенной временной переменной t (§8.5).Некоторые языковые конструкции требуют преобразования выражения в логическое значение.Выражение e, появляющееся в таком контексте, называется контекстно преобразованным в bool и правильно сформировано тогда и только тогда, когда объявление bool t(e); правильно сформировано , для некоторой изобретенной временной переменной t (§8.5).

Выделенная часть ясно показывает «неявное явное приведение» (называемое «контекстное преобразование» в стандарте) как @R.Мартиньо сказал:

«Определенные языковые конструкции», требующие «неявного явного приведения», выглядят следующим образом:

• if, while, for(§6.4 [stmt.select] p4)
• двоичные логические операторы && и || (§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)

Isнаше предположение в названии верно?Надеюсь, мы не упустили ни одного потенциального недостатка.

Answer 1

Да. Это пример для проблем с наличием только неявных пользовательских преобразований, а явные пользовательские операторы преобразования были практически изобретены из-за этой проблемы и для замены всего материала safe-bool что-то намного чище и логичнее.

Answer 2

Я бы не назвал это "устаревшим". Не все делают скачок в C ++ 11 (даже 1 год возраст) пока. И даже если бы было достаточное количество кодеров, необходимость поддерживать код обратно совместимым была бы необходимостью, учитывая, что этот вид идиомы кажется более разумным для библиотек, чем для самих программ.