Чи застаріла ідіома безпечного була в 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)

Чи правильне наше припущення в назві? Сподіваюся, ми не упустили жодних потенційних недоліків.

— Ксео
джерело

+1: Я люблю такий тип запитань, який навчає мене нових речей про майбутній стандарт.

— Björn Pollex

Ви знаєте, чого в стандарті відсутній явний чіткий склад ... повернення чогось іншого operator bool. Наприклад, якщо у мене є shared_ptrчлен p, який називається p і є цей метод:, operator bool() const { return p; }він не може компілювати. Це дурне ІМО.

— Девід

Що ви маєте на увазі під "неявним явним" актором, @David?

— Sz.

Відповіді:

128

Так. Це приклад проблем з тільки при наявності неявних певного користувача перетворення і явні оператори , що визначається користувач перетворення практично були винайдені з - за цю проблему і замінити все сейф-Ій матеріал з чим - то набагато більш чистим і більш логічним.

— Щеня
джерело

-5

Я б не назвав це "застарілим". Далеко не кожен робить цей стрибок на C ++ 11 (навіть не один рік ). І навіть якби хороша кількість кодерів була, можливість збереження коду назад сумісним було б обов'язковим, враховуючи такий тип ідіоми здається більш розумним для бібліотек, ніж для власне програм.

— Луїс Мачука
джерело

Я суто говорив у присутності С ++ 11. Це питання не стосується старого коду, зворотної сумісності або небажання змінювати компілятори, обізнані на C ++ 11. Також зауважте, що C ++ 11 сам по собі не є повністю порівнянним назад, він вніс переломні зміни.

— Xeo

Не міг би це знати, вибач. Я не розглядав лише відповідь, пов’язаний на початку, а й той факт, що питання позначено тегами [c ++] та [c ++ - faq], що змусило мене думати, що оцінка обох етапів мови є релевантною.

— Луїс Мачука

Ви, звичайно, маєте рацію, я прямо не сказав цього питання. Я відредагую це, спасибі за голову вгору.

— Xeo

Ця відповідь справді могла б використовувати оновлення, оскільки вже майже два роки.

— Щеня

Мені доведеться відмовитись через незгоду, хоча я б придбав тобі пиво особисто і сказав "ей, не важкі почуття". Але багато парадигм у С ++ 11 зазнавали розгортання, --std=c++0xзадовго до того, як остаточний цвях був забитий у труну стандартів, і вони вирішили поставити цю назву на специфікацію ISO. Якщо ви не дуже глибокий метапрограмуючий наркоман, деталі специфікації C ++ 11 проти того, що люди використовували, для вас, ймовірно, не матимуть ніяких наслідків ... це означає, що він був старший за 2011 рік для майже всіх практичних цілей навіть тоді. А зараз, за моїм годинником, майже 2015 рік.

— HostileFork каже, що не довіряйте SE