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

179

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

explicit operator bool() const;

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

Выражение e может быть неявно преобразовано в тип Tтогда и только тогда, когда объявление T t=e;правильно сформировано, для некоторой изобретенной временной переменной t(§8.5). Некоторые языковые конструкции требуют, чтобы выражение было преобразовано в логическое значение. Выражение eпоявляется в таком контексте , как говорит, контекстуально преобразовано в boolи хорошо сформировано , если и только если декларация bool t(e);хорошо сформирована , в течение некоторого изобретенный временного переменного т (§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)

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

— Xeo
источник

+1: мне нравится этот тип вопросов, который учит меня новым вещам о предстоящем стандарте.

— Бьорн Поллекс

Вы знаете, что неявное явное приведение отсутствует в стандарте ... возвращая что-то от другого operator bool. Например, если у меня есть shared_ptrчлен с именем p и у меня есть этот метод:, operator bool() const { return p; }он не скомпилируется. Это глупо ИМО.

— Дэвид

Что вы подразумеваете под "неявным явным" приведением, @David?

— СЗ

Ответы:

128

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

— щенок
источник

-5

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

— Луис Мачука
источник

Я чисто говорил в присутствии C ++ 11. Этот вопрос не касается старого кода, обратной совместимости или нежелания переходить на компиляторы с поддержкой C ++ 11. Также обратите внимание, что C ++ 11 сам по себе не полностью совместим с предыдущими версиями, он внес серьезные изменения.

— Xeo

Извините, я бы этого не знал. Я рассматривал не только ответ, связанный с самого начала, но и тот факт, что вопрос помечен [c ++] и [c ++ - faq], что привело меня к мысли, что оценка обоих этапов языка была актуальной.

— Луис Мачука

Вы, конечно, правы, хотя я не указал это явно в вопросе. Я отредактирую это, спасибо за заголовки.

— Xeo

Этот ответ может действительно использовать обновление, теперь, когда ему почти два года.

— Щенок

Мне придется понизить голосование из-за разногласий, хотя я лично куплю тебе пиво и скажу: «Эй, никаких обид». Но многие парадигмы в C ++ 11 находились в процессе развертывания --std=c++0xзадолго до того, как последний гвоздь был забит в гроб стандартов, и они решили поставить имя в спецификации ISO. Если вы не очень любитель шаблонного метапрограммирования, подробности спецификации C ++ 11 и того, что использовали люди, скорее всего, не будут иметь для вас никакого значения ... это означает, что он был старше 2011 года практически для всех практических целей даже тогда. И теперь, по моим часам, уже почти 2015 год.

— HostileFork говорит, что не доверяйте SE