L'idiome safe-bool est-il obsolète en C++11?

Question

Cette réponse de @R. Martinho Fernandes montre que l'idiome safe-bool est apparemment obsolète en C++11, car il peut être remplacé par un simple

explicit operator bool() const;

selon la citation standard dans la réponse §4 [conv] p3:

Une expression e peut être implicitement convertie en un type T si et seulement si la déclaration T t=e; est bien formée, pour une variable temporaire inventée t (§8.5). Certains constructions linguistiques exigent qu'une expression soit convertie en une valeur booléenne. Une expression e apparaissant dans un tel contexte est dite convertie contextuellement en bool et est bien formée si et seulement si la déclaration bool t(e); est bien formée, pour une variable temporaire inventée t (§8.5).

La partie mise en évidence montre clairement le "cast implicite explicite" (appelé "conversion contextuelle" dans le standard) tel que décrit par @R. Martinho.

Les "constructions linguistiques" qui nécessitent ce "cast implicite explicite" semblent être les suivantes:

• if, while, for (§6.4 [stmt.select] p4)
• opérateurs logiques binaires && et || (§5.14 [expr.log.and/or] p1 pour les deux)
• l'opérateur de négation logique ! (§5.3.1 [expr.unary.op] p9)
• opérateur ternaire ?: (§5.14 [expr.cond] p1)
• static_assert (§7 [dcl.dcl] p4)
• noexcept (§15.4 [except.spec] p2)

Notre hypothèse dans le titre est-elle correcte? J'espère que nous n'avons pas négligé d'éventuels inconvénients.

Answer 1

Oui. C'est l' exemple pour les problèmes liés au fait de n'avoir que des conversions implicites définies par l'utilisateur et les opérateurs de conversion définis par l'utilisateur étaient pratiquement inventés à cause de ce problème et pour remplacer tout le bazar safe-bool par quelque chose de beaucoup plus propre et logique.

Answer 2

Je ne qualifierais pas cela d' "obsolète". Tout le monde n'a pas encore fait le saut vers le C++11 (qui n'a même pas encore 1 an). Et même si un bon nombre de codeurs le faisaient, la capacité de conserver la compatibilité ascendante du code serait incontournable, étant donné que ce genre d'idiome semble plus judicieux pour les bibliothèques que pour les programmes proprement dits.