Surcharge du constructeur

Bonjour :coucou:

Voici un petit programme qui ne se comporte pas comme je le voudrais (CodeBlocks 13.12 sur Windows 7)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

#include <iostream> #include <string>   using namespace std;   class EMC { unsigned bof ;   public:   EMC(string s = "0"){cout<<endl<<"s = "<<s ;} ; EMC(unsigned n = 0){cout<<endl<<" n = "<<n ;} ; EMC(unsigned long long n = 0){cout<<endl<<" n = "<<n ;} ;   ~EMC(){ ;} ; };   int main() { EMC u("ok"); // EMC v = "pas ok" ; EMC w = (string)"ok" ;   return 0; }

---

Tel quel, il fonctionne. Mais voici le message reçu si on décommente la ligne.
Pièce jointe 151016


J'ai deux questions :

1. la ligne commentée n'est-elle pas équivalente à la première ?
2. pour lever l'ambiguïté pourquoi, sur les 3 constructeurs présents, le compilateur n'envisage-t-il pas le seul qui fonctionne ? La troisième ligne semble montrer qu'il le trouve si on l'aide un peu ...

Merci d'avance

Parce que je pense que le compilateur voit 3 constructeurs par défaut (sans arguments)

Tu croyais quoi? Qu'il allait faire un jet de dés :koi:

Mets un explicit devant le constructeurs qui prend en paramètre un type string :whistle:

Bonjour foetus :coucou:

Merci d'avoir répondu. Mais vu le niveau de mes connaissances, je vais avoir besoin d'un peu plus de détails. :oops:

Citation:

---

Envoyé par foetus

Parce que je pense que le compilateur voit 3 constructeurs [...]

---

Parfois, il semble n'en voir que 2 (question 2)

Citation:

---

[..] par défaut (sans arguments)

---

J'ai retiré les valeurs par défaut, cela ne change rien.

Citation:

---

Tu croyais quoi? Qu'il allait faire un jet de dés :koi:

---

Il semble bien que, dans certains cas, il arrive à faire son choix :

• la ligne 22 montre qu'il se débrouille très bien, si on lui demande comme il faut.
• la ligne 23 renvoie à ma question 1
• la ligne 24 montre que si on convertit "ok" en string, ça marche : question "ok" n'est-il pas déjà une valeur de type string ?
• Si on ajoute : string s = "ok" ; alors EMC x = s ; fonctionne.

Citation:

---

Mets un explicit devant le constructeurs qui prend en paramètre un type string :whistle:

---

Après avoir enlevé les valeurs par défaut, j'ai mis explicit devant le premier EMC (ligne 13).

• la ligne 22 fonctionne toujours,
• la ligne 23, toujours pas,
• la ligne 23 et EMC x = s ; ne fonctionnent plus. Cela signifie qu'il y avait une conversion implicite utile avant, mais laquelle ?

Je ne sais pas vraiment quoi faire : peux-tu modifier ce programme pour qu'il fonctionne? :mrgreen:

Merci encore

Désolé :wow: mais en lisant EMC v = "pas ok" ; j'ai compris EMC v pas ok :roll:

Tu n'apelles pas les constructeurs mais les opérateur d'affectation. Le compilateur, intelligent, l'optimisera surement en appel au constructeur.
"ok" n'est pas une string mais un const char* (ou peut-être const char[]), le fait est que std::string a un constructeur qui prend un const char* : ça s'apelle une conversion implicite
1 seule et unique conversion implicite peut être faite lors de l'appel à une méthode.

@Bousk: La syntaxe T t = u; ce n'est en aucun cas un appel à une affectation, c'est une syntaxe d'initialisation au même titre que T t(u); (et d'autre en C++11).

@foetus: La question c'est pourquoi EMC u("ok"); fonctionne et pas EMC v = "pas ok";.

@OP: En général on considère que ces deux syntaxes sont strictement équivalentes (EMC u("ok"); et EMC v = "pas ok";). En réalité ce n'est pas le cas, la première se nomme "initialisation direct" et la seconde "initialisation par copie", les mécanismes sont un peu différents :

• Pour la première il regarde les différents constructeur, et il essaie de "faire correspondre" le type de "ok" au type de ton argument (std::string donc).
• Pour la seconde, il essaie directement de "faire correspondre" le type de "pas ok" au type de ta classe (EMC donc).

Reste à savoir ce que veut dire "faire correspondre", ici ça veut dire "une séquence de conversion permettant d'aller d'un type à un autre", une conversion pouvant être définie de différentes manières, dont une est une constructeur (non explicite). D'autre part certaines règles sont imposées à ces séquences, entre autre (et pour faire simple) une seule conversion définie par un constructeur (non explicite) dans la séquence (ce que disait Bousk)

Dans ton cas, on veut aller de const char[N] à std::string ou EMC, on a :

• Une conversion de const char[N] à const char* (c'est une conversion "naturelle")
• Une conversion de const char* à std::string (définit par constructeur)
• Une conversion de std::string à EMC (définit par constructeur)

Donc dans ton premier appel on arrive à "faire correspondre" sans problème le type de "ok" à std::string, par contre dans le second on ne peut pas "faire correspondre" le type de "pas ok" à EMC car ceci impliquerait deux conversions définies par constructeur (non explicite).

Code minimal illustrant le problème :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include<string>   struct A { A(std::string){} };   int main() { A a("a"); //Compile A b = "b"; //Ne compile pas }

---

Bonjour :coucou:

Merci à tous pour vos réponses.
Il va me falloir un peu de temps pour digérer tout ça!

Amicalement

Bonjour :coucou:

Désolé, j'ai du m'absenter quelques jours.

Je ne prétends pas avoir compris toutes les subtilités mais il me semble y voir un peu plus clair.

Voici un petit programme qui marche très bien.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

#include <iostream> #include <string>   using namespace std;   class EMC { unsigned bof ;   public:   EMC(){cout<<endl<<"{}";}; EMC(const string s){cout<<endl<<"string : "<<s ;} ; EMC(const char *s){cout<<endl<<"char *s : "<<s ;} ; EMC(unsigned long long n){cout<<endl<<" n : "<<n ;} ;   ~EMC(){ ;} ; };   int main() { string s = "10" ; EMC x(s) ; EMC y = s; EMC u("20"); EMC v = "30" ; EMC w = (string)"40" ;   EMC a ; a = EMC("50"); a = (EMC)"60"; a = EMC(70) ; a = (EMC) 80 ;   EMC b = 90; EMC c(100);   return 0; }

---

Les résultats :

string : 10 //
string : 10 //
char *s : 20 //
char *s : 30 //
string : 40 //
{} //
char *s : 50 //
char *s : 60 //
n : 70 //
n : 80 //
n : 90 //
n : 100 //


Merci à tous. :lahola:

PS : reste un truc concernant mon post de départ. Question 2 : pourquoi le compilateur ne considère-t-il que 2 candidats sur les 3 présents :question:
Une dernière réponse pour la route ? :mrgreen:

Citation:

---

Envoyé par serge17

Question 2 : pourquoi le compilateur ne considère-t-il que 2 candidats sur les 3 présents :question:
Une dernière réponse pour la route ? :mrgreen:

---

En gros (parce qu'en détails, c'est compliqué), pour choisir quelle surcharge prendre, le compilateur fait à peu près ça :
- Il élimine les fonctions qui ne marcheraient pas (pas le bon nombre d'arguments, des arguments de types non compatibles...)
- Il essaye de trier les fonctions par ordre de préférence
- Si ce tri dit qu'il y a une unique fonction meilleure que toutes les autres il la prend, sinon, ambiguïté.

Et parmi ses règles d'ordre de préférence, il préfère une conversion entre types de base (par exemple, pointeur vers entier) à une conversion faisant intervenir un constructeur (par exemple char* en string).

Dans ton cas :
- unsigned int est mieux que string
- unsigned long long est mieux que string
- entre unsigned int et unsigned long long, il ne sait pas décider

Donc même si au final il ne sait pas décider, c'est uniquement entre deux versions qu'il hésite, et donc il ne mentionne pas la troisième.

Et enfin, en C++14, tu pourrais remplacer EMC w = (string)"ok" ; par EMC w = "ok"s ;.

Merci JolyLoic :ccool:

Je passe en résolu