surcharge de fonction, bool et string

Bonjour,

je vous propose une petite question piège. Prenons le code suivant:

Code:

---

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

void f( const std::string & str ) { std::cout << "string" << std::endl; } void f( bool b ) { std::cout << "bool" << std::endl; }   main() { std::string str = "test"; bool b = false;   f( "test" ); f( true ); f( str ); f( b ); f( "" ); }

---

Question: quel est l'output de ce programme?

Approfondissement de la question: pourquoi?

Selon moi:
bool
bool
string
bool
bool

Tout simplement parce que "" est une chaîne vide, doit un const char* qui sera transtypé en bool avant std::string ;)
Pour forcer le transtypage en string, il faut l'expliciter avec f(std::string(""));

héhé, tu as évité un piège, mais tu es tombé dans le second ;p
essaie de compiler...

d'ailleurs, si quelqu'un a une version récente de gcc et pouvais tester, ça pourrait être intéressant (je n'ai pas de gcc sous la main).

J'aurais dit comme Bousk... et gcc confirme :

Citation:

---

bool
bool
string
bool
bool

---

J'ai compilé (moyennant l'ajout des includes etc) sur visual 2010, et j'obtiens exactement ça :calim2:

Quel résultat as-tu ? Lequel attends-tu ?

ooops oui, vous avez raison, my bad :oops:
oui oui, j'obtiens bien la même chose avec ms vc.
J'ai confondu sur le premier appel: f( "test" ); j'ai cru que tu disais que ça appelais la version f(const std::string &);

Vous avez donc bien répondu tous les deux, sorry :oops:

Il est quand même étrange que les appels 1 et 5 n'émettent pas une erreur "appel ambigu" à la compilation... puisque c'est manifestement le cas, non ?

Une petite source, pour les explications : http://en.cppreference.com/w/cpp/language/implicit_cast

Ce qui se passe, c'est que le compilateur à le choix entre une conversion du pointeur en bool (voir la partie "Boolean conversions") ou appeler un constructeur de conversion. La règle de résolution des noms (indiqué en haut de page) indique qu'une conversion implicite standard est préférée à la conversion par appel d'une fonction définie par l'utilisateur

EDIT : @cob59, sur MSVC, c'est l'erreur C4800 (mais je sais pas comment on l'active ou si elle est activée par défaut)