Constructeur de conversion et opérateur de conversion: priorité

Question

La lecture de quelques questions ici DONC, au sujet de la conversion des opérateurs et des constructeurs m'a fait réfléchir sur l'interaction entre eux, notamment lorsqu'il y a un "ambigu" appel. Considérons le code suivant:

class A;

class B { 
      public: 
         B(){} 

         B(const A&) //conversion constructor
         { 
              cout << "called B's conversion constructor" << endl; 
         } 
};

class A { 
      public: 
         operator B() //conversion operator
         { 
              cout << "called A's conversion operator" << endl; 
              return B(); 
         } 
};

int main()
{
    B b = A(); //what should be called here? apparently, A::operator B()
    return 0;
}

Le code ci-dessus affiche "appelé l'opérateur de conversion", ce qui signifie que l'opérateur de conversion est appelée ainsi par opposition au constructeur. Si vous supprimez/commentaire l' operator B() code de A, le compilateur sera heureux de passer de l'un à l'aide du constructeur de la place (avec aucune autre modification du code).

Mes questions sont les suivantes:

1. Puisque le compilateur ne pas envisager B b = A(); à l'ambiguïté d'un appel, il doit y avoir un certain type de préséance à l'œuvre ici. Où est exactement ce préséance établi? (document de référence/citation de la norme C++ serait appréciée)
2. À partir d'un orientée objet philosophique point de vue, est-ce la façon dont le code doit se comporter? Qui en sait plus sur la façon dont un A objet doit devenir un B objet, A ou B? En fonction de C++, la réponse est A -- existe-t-il orienté objet pratique qui suggère que ce devrait être le cas? Pour moi personnellement, il serait bon de toute façon, donc je suis curieux de savoir comment le choix a été fait.

Merci d'avance

Answer 1

Vous ne copie de l'initialisation, et le candidat fonctions qui sont considérés comme de faire les conversions à la conversion de la séquence sont des fonctions de conversion et la conversion des constructeurs. Ces sont dans votre cas

B(const A&)
operator B() 

Maintenant, qui sont la façon dont vous les déclarer. Résolution de surcharge des résumés à l'écart de cela, et transforme chaque candidat dans une liste de paramètres qui correspondent aux arguments de l'appel. Les paramètres sont

B(const A&)
B(A&)

Le second est parce que la fonction de conversion est une fonction membre. L' A& , est dite implicite paramètre de l'objet qui est générée lorsqu'un candidat est une fonction membre. Maintenant, l'argument est de type A. Lors de la liaison de l'objet implicite d'un paramètre non-const de référence peut se lier à une rvalue. Donc, une autre règle dit que quand vous avez deux viable fonctions dont les paramètres sont des références, le candidat ayant le moins de const qualification va gagner. C'est pourquoi votre fonction de conversion gagne. Essayez de faire d' operator B const fonction membre. Vous remarquerez une ambiguïté.

À partir d'un orientée objet philosophique point de vue, est-ce la façon dont le code doit se comporter? Qui en sait plus sur la façon dont Un objet doit devenir un objet B, A ou B? En fonction de C++, la réponse est -- il n'y a rien orientée objet pratique qui suggère que ce devrait être le cas? Pour moi personnellement, il serait bon de toute façon, donc je suis curieux de savoir comment le choix a été fait.

Pour l'enregistrement, si vous faites de la fonction de conversion d'une fonction membre const, puis GCC choisi le constructeur (donc GCC semble penser qu' B a plus d'affaires avec elle?). Commutateur de mode pédant (-pedantic) pour le faire causer un diagnostic.

---

Standardese, 8.5/14

Dans le cas contraire (c'est à dire, pour le reste de la copie de l'initialisation des cas), défini par l'utilisateur de conversion de séquences que vous pouvez convertir le type de la source à la destination, le type ou (lorsque la fonction de conversion est utilisé) à une classe dérivée de celle-ci sont énumérés comme décrit dans 13.3.1.4, et le meilleur est choisi par le biais de la résolution de surcharge (13.3).

Et 13.3.1.4

Résolution de surcharge est utilisé pour sélectionner la conversion définie par l'utilisateur pour être invoqué. En supposant que "cv1 T" est le type de l'objet en cours d'initialisation, avec T un type de classe, le candidat fonctions sont sélectionnées comme suit:

• La conversion de constructeurs (12.3.1) de T sont des fonctions candidates.
• Lorsque le type de l'initialiseur d'expression est une classe de type "cv S", les fonctions de conversion de S et de ses classes de base sont pris en compte. Ceux qui ne sont pas cachés dans les S et les rendements d'un type dont le cv-version non qualifiés est du même type que T est une classe dérivée de celle-ci sont des fonctions candidates. Des fonctions de Conversion qui retour "de référence à X" retour lvalues de type X et sont donc considérés comme rendement de X pour ce processus de sélection des candidats fonctions.

Dans les deux cas, l'argument de la liste a un argument, qui est l'initialiseur d'expression. [Note: cet argument peut être comparé avec le premier paramètre de constructeurs et à l'encontre de l'objet implicite paramètre des fonctions de conversion. ]

Et 13.3.3.2/3

• De conversion Standard de la séquence S1 est un meilleur taux de conversion de la séquence de conversion standard de la séquence S2 si [...] S1 et S2 sont référence des liaisons (8.5.3), et les types dont les références se rapportent sont du même type, sauf pour le haut-niveau cv-qualificatifs, et du type dans laquelle la référence initialisé par le S2 fait plus de cv qualifiés que le type à qui la référence initialisé par S1 désigne.

Answer 2

Il semble MSVS2008 a sa propre opinion sur constructeur de sélection: il appelle constructeur de copie de B, quelles que soient constness de l'opérateur. Donc attention, ici même alors que la norme spécifie le comportement correct.

J'ai pensé MSVS il suffit de chercher pour le constructeur approprié avant que les conversions de l'opérateur, mais qu'il commence à appeler Un opérateur B() si vous supprimez const mot de B du constructeur. Probablement, il en a quelques un comportement particulier pour les temporaires, parce que le code suivant appelle encore B du constructeur:

A a;

B b = a;