Quel est la difference?

Bonjour,
y as un truc que je ne pige pas trop. dans ce code

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#include <iostream> #include <string> using namespace std; struct A { A(string & s):m_s(s){}; string m_s; };     int main() { A a("essai"); cout << a.m_s << endl; return 0; }

---

fait une erreur car "essai" n'est pas une string et ne peut donc être passé en référence. Ca ok.
Par contre en ajoutant const dans le constructeur de A

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#include <iostream> #include <string> using namespace std; struct A { A(string const & s):m_s(s){}; string m_s; };     int main() { A a("essai"); cout << a.m_s << endl; return 0; }

---

ce code compile et fonctionne!!!

La différence est que le deuxième peut servir d'opérateur de conversion implicite sous une forme qui serait proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void lafonction(const A& lavar) {   } int main() { std::string ch="salut"; lafonction(ch); /*...*/ return 0; }

---

Cela signifie que, si tu veux empêcher cette conversion automatique, tu devrais déclarer le constructeur sous la forme de

Code:

---

explicit A(const std::string&)

---

Il me semble d'ailleurs que tu économisera une copie en passant le paramètre sous la forme de référence constante ;)

J'vais peut-etre dire des betises, mais il me semble que je sais pourquoi...

Quand tu declare une chaine par "essai" au sein de ton code, le compilateur alloue un espace memoire pour cette chaine, y copie les caracteres e,s,s,a et i (peut-etre aussi un 0 terminal)

Vu que tu as declaré cette chaine au sein de ton code, elle n'est pas allouée de façon dynamique, mais statique. Il ne faut donc pas laisser la possibilité au programmeur de modifier ce qu'il y a à ton adresse, car il risquerais d'ecraser d'autres constantes du programme (si tu y ecrit une chaine plus longue, par exemple)

Donc, en specifiant const, ça marche, puisque "essai" est en fait un pointeur const vers une chaine.

Et vu la signature de ta fonction, le compilateur a compris tout seul qu'il ne fallait pas créer une variable de type const char* en mémoire, mais une variable de type const string

Ceci explique cela.

A peu de choses près...

En fait, il faut bien comprendre que tu as un constructeur par copie pour la std::string qui est, comme tu t'en doutes, string(const std::string&)...

D'un autre coté, tu as un constructeur de string qui correspond (grace au spécialisations, on est d'accord hein :D) à string(const char*), mais qui est déclaré, sauf erreur, comme explicite (ne permet pas de créer la chaine sans spécifier qu'on veut le faire)...

Dés lors, quand tu déclare ton constructeur sous la forme de

Code:

---

A(std::string& ch)

---

il faut que tu fournisse une chaine existante, alors que, quand tu le déclare sous la forme de

Code:

---

A(const std::string& ch)

---

tu en arrive à:

• créer une chaine temporaire avec le constructeur explicite qui
• sera utilisé pour créer la chaine passée en argument grace au constructeur par copie et qui
• servira pour le constructeur de A...

Ce n'est surement pas tout à fait juste, mais l'idée générale est là ;)

A a("essai"); crée un temporaire non-nommé de type string pour le passer au constructeur de a.
La norme refuse le passage par référence non-constante de temporaire non-nommé, mais je ne me souviens plus des raisons précises (entre autres, modifier un truc sur le point d'être détruit n'a pas vraiment de sens).

Un troisième point de vue:

En fait, le constructeur qui prend un unique objet par référence constante est appelé également opérateur de conversion.

Par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

struct Dum { Dum(const int & num) { std::ostringstream oss; oss << num; m_str = oss.str(); } std::string m_str; };   int main() { Dum dum = 3; // convertion de int en Dum }

---

C'est une autre façon de voir les choses, mais ça explique un peu aussi ce qu'il se passe.

Citation:

---

Envoyé par Médinoc

A a("essai"); crée un temporaire non-nommé de type string pour le passer au constructeur de a.
La norme refuse le passage par référence non-constante de temporaire non-nommé, mais je ne me souviens plus des raisons précises (entre autres, modifier un truc sur le point d'être détruit n'a pas vraiment de sens).

---

C'est bien ce que je pensais.
C'est super ça en faite:king:.
Mon problème n'était pas le constructeur mais le fait de pouvoir passer une chaîne de caractère de type C sur un "string const &".
Je trouve cela trés puissant en faite.
Ainsi pour une même fonction:
1- le passage d'un string en paramètre d'entrée sera optimisé
2- Mais on pourra y mettre autre chose. Du moment que l'on puisse le convertir en string

Par rapport au thread de koala01 sur les références. Ca en montre un autre difference avec un pointeur, qui je trouve, n'est pas négligeable.

Voici un autre code

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include <iostream> #include <string> using namespace std;   void test( string const & s) { cout << s << endl; } int main() { test("essai"); return 0; }

---

Attention au revers de la médaille, toutefois...
http://blogs.msdn.com/oldnewthing/ar...24/605974.aspx

Citation:

---

Envoyé par Médinoc

Attention au revers de la médaille, toutefois...
http://blogs.msdn.com/oldnewthing/ar...24/605974.aspx

---

C'est à dire?

C'est à dire que, justement, si tu déclares un argument comme référence constante, tu cours le risque de faire appel à un opérateur de conversion implicite...

Pour une chaine de caractères, ce n'est pas *trop* grave, mais l'exemple présente un cas particulier qui peut, justement, provoquer des couacs majeurs ;)

Citation:

---

Envoyé par koala01

C'est à dire que, justement, si tu déclares un argument comme référence constante, tu cours le risque de faire appel à un opérateur de conversion implicite...

Pour une chaine de caractères, ce n'est pas *trop* grave, mais l'exemple présente un cas particulier qui peut, justement, provoquer des couacs majeurs ;)

---

Ha ok. mais d'où l'utilisation de explicit :D
lol, je croit que je viens de comprendre explicit

En fait, l'utilisation de explict sur le constructeur va obliger d'utiliser un objet existant lorsque l'on veut fournir un l'objet en parametre de fonction:
Ainsi, la classe

Code:

---

1 2 3 4 5

class LaClass { public: LaClass(int i); };

---

permettrait d'appeler une fonction ayant le prototye de

Code:

---

void lafonct(const LaClass& );

---

sous une forme proche de

Code:

---

1 2	int i; lafonct(i);

---

du fait que le constructeur prenant un seul argument sert d'opérateur de conversion...

Par contre, si tu crée ta classe sous la forme de

Code:

---

1 2 3 4 5

class LaClass { public: explicit LaClass(int i); };

---

les seuls moyens pour pouvoir appeler la même fonction seront

Code:

---

1 2 3 4 5 6

int i; lafonct(LaClass(i)); /* OU */ LaClass a(i); lafonct(a);

---

et l'appel de

Code:

---

lafonct(i);

---

provoquera une erreur de compilation...

Voilà, tu sais maintenant tout :D

Citation:

---

Envoyé par Médinoc

La norme refuse le passage par référence non-constante de temporaire non-nommé, mais je ne me souviens plus des raisons précises (entre autres, modifier un truc sur le point d'être détruit n'a pas vraiment de sens).

---

C'est ça en gros. Sauf qu'en plus d'être sur le point d'être détruit, l'utilisateur n'y a même pas accès. L'exemple de base est

Code:

---

1 2 3 4 5 6

void incr(int &i) {++i;} int main() { double i = 0; incr(i); }

---

S'il n'y avait pas cette règle, le code compilerait, mais ce serait probablement une erreur, la variable incrémentée étant le temporaire crée du manière invisible pour l'utilisateur.

Le problème là n'est il pas plus un problème de conversion de int en double :question:

Je verrais personnellement bien pour reprendre ton exemple, et pour présenter le cas particulier un problème avec

Code:

---

1 2 3 4 5

void incr(int &i) {++i;} int main() { incr(3); }

---

qui provoque une erreur

Citation:

---

invalid initialization of non-const reference

---

(meme si, de fait, on peut considérer que le code que tu présente fait appel à un opérateur de conversion implicite de double en int ;))

Incrémenter 3 est demander d'incrémenter une constante, et non un temporaire. On n'est donc pas dans le cas de la règle en question.

Incrémenter i peut sembler légitime à l'utilisateur, et compilerait et s'exécuterait sans cette règle, mais aurait un comportement surprenant (il le faisait dans les premières versions du C++). La conversion a créé un temporaire, et il est rare qu'on veuille le modifier.

Citation:

---

Envoyé par JolyLoic

Incrémenter 3 est demander d'incrémenter une constante, et non un temporaire. On n'est donc pas dans le cas de la règle en question.

Incrémenter i peut sembler légitime à l'utilisateur, et compilerait et s'exécuterait sans cette règle, mais aurait un comportement surprenant (il le faisait dans les premières versions du C++). La conversion a créé un temporaire, et il est rare qu'on veuille le modifier.

---

OOOpppsss... de fait... j'étais un peu distrait sur ce coup... :aie:

My 2 cents : moi je pense que ça avoir avec les lvalue vs. rvalue...

Et ça me fait énormément penser à ce sujet : http://www.developpez.net/forums/sho...d.php?t=444881

Mais je peux me tromper.

Citation:

---

Envoyé par NiamorH

My 2 cents : moi je pense que ça avoir avec les lvalue vs. rvalue...

Et ça me fait énormément penser à ce sujet : http://www.developpez.net/forums/sho...d.php?t=444881

Mais je peux me tromper.

---

Ouai c'est la même famille :aie:.
C'est cool, ça complète la réponse, je trouve.