opérateur de conversion comme fonction autonome

Question

Pourquoi le C++ exige-t-il que l'opérateur de conversion défini par l'utilisateur ne puisse être qu'un membre non statique ? Pourquoi n'est-il pas permis d'utiliser des fonctions autonomes comme pour les autres opérateurs unaires ? Quelque chose comme ceci :

operator bool (const std::string& s) { return !s.empty(); }

Answer 1

La seule raison qui me vient à l'esprit est d'éviter que des conversions implicites soient appliquées à l'objet du moulage. Dans votre exemple, si vous dites :

 bool( "foo" );

alors "foo" serait implicitement converti en une chaîne de caractères, à laquelle serait appliquée la conversion bool explicite que vous avez fournie.

Cela n'est pas possible si l'opérateur bool est une fonction membre, car les conversions implicites ne sont pas appliquées à l'opérateur bool. *this . Cela réduit considérablement les possibilités d'ambiguïté - les ambiguïtés étant normalement considérées comme une "mauvaise chose".

Answer 2

En gardant l'opérateur de conversion à l'intérieur de la classe, vous donnez à l'auteur de la classe le contrôle de la façon dont elle pourrait être convertie (Cela empêche les utilisateurs de créer des implicite conversions). En tant que responsable de la mise en œuvre, je considérerais cela comme un avantage, car les conversions implicites ont leurs problèmes

Il y a une différence entre le fait de pouvoir faire passer un objet pour un autre, et le fait de devoir passer par une fonction de conversion. Le premier communique que l'objet est d'un type donné, tandis que le second montre aux nouveaux lecteurs qu'il existe une différence entre les deux types et qu'une conversion est nécessaire.

Answer 3

Il y a un groupe d'opérateurs qui doivent être surchargés en tant que fonctions membres non statiques : affectation, inscription, appel de fonction, accès aux membres de la classe, fonctions de conversion.

Je suppose que le comité de la norme ou M. Stroustrup ont simplement estimé qu'il y aurait trop de confusion si l'on autorisait l'injection de ces comportements très spéciaux dans les classes depuis l'extérieur.

---

Je suppose que la meilleure façon d'obtenir la réponse serait d'envoyer un e-mail à l'auteur.

Answer 4

Les conversions implicites définies par l'utilisateur sont de toute façon désapprouvées. Ne les utilisez pas. Faites comme si elles n'existaient pas. Sans parler de réfléchir à de nouvelles façons de les introduire.

De toute façon, je suppose qu'ils ne sont pas là parce que, tels qu'ils sont, ils peuvent faire suffisamment de choses inattendues. Inclure un nouvel en-tête qui introduit une telle conversion pour une classe définie ailleurs pourrait conduire à des erreurs encore plus déroutantes.