2009-12-23 4 views
3

Je reçois une erreur qui indique que deux surcharges ont des conversions similaires. J'ai essayé trop de choses mais aucune n'a aidé.Surcharge de fonction C++ Conversions similaires

est que morceau de code

CString GetInput(int numberOfInput, BOOL clearBuffer = FALSE, UINT timeout = INPUT_TIMEOUT); 
CString GetInput(int numberOfInput, string szTerminationPattern, BOOL clearBuffer = FALSE, UINT timeout = INPUT_TIMEOUT); 

Je ne comprends pas comment pourrait-chaîne égale à longue?

J'utilise Visual C++ 6 (eh oui je sais que son vieux, je travaille sur le code existant, donc je suis à peu près sans défense)

EDIT: La ligne de code qui déclencherait la erreur est

l_szOption = GetInput(13, FALSE, 30 * 10); 
+0

Est-ce que string == std :: string? – AraK

+0

Quelle ligne de code déclenche l'erreur? –

+0

yep, string == std :: string – akif

Répondre

4

Le problème est causé par le fait que vous fournissez l'argument de délai d'attente en tant que signé valeur entière, qui doit être converti à un non signé pour la première version de la fonction (puisque le paramètre timeout est déclaré UINT).

I.e. la première version de la fonction nécessite une conversion pour le troisième argument, tandis que la deuxième version de la fonction nécessite une conversion pour le deuxième argument (FALSE, qui est juste 0, à string). Dans ce cas, aucune fonction n'est meilleure que l'autre et la résolution de surcharge échoue.

Essayez de donner explicitement le troisième argument du type non signé

l_szOption = GetInput(13, FALSE, 30U * 10); 

ou

l_szOption = GetInput(13, FALSE, (UINT) 30 * 10); 

(selon ce que vous préférez) et le code devrait compiler comme prévu. En d'autres termes, le compilateur a tout à fait raison de se plaindre de votre code.

Votre code est en effet cassé. Le problème dans votre code a exacty la même nature que dans l'exemple simple suivant

void foo(int i, unsigned j); 
void foo(unsigned i, int j); 

int main() { 
    foo(0, 0); 
} 

Ce code sera également ne pas compiler précisément pour la même raison.

1

Vous passez peut-être cette fonction un second paramètre qui est ni BOOL, ni string, mais un type qui pourrait être converti implicitement non plus.

Un pointeur de caractère, par exemple.

1

Pour résoudre l'ambiguïté lorsque vous appelez la fonction, transtypez le deuxième paramètre en BOOL ou utilisez string("whatever") s'il s'agit bien de std :: string.

+0

La conversion 'FALSE' en' BOOL' ne résoudra pas l'ambiguïté dans ce cas. '(BOOL) FALSE' est toujours une forme valide de la constante null-pointer, ce qui signifie qu'elle reste convertible en' std :: string'. – AnT

1

Tenir compte le cas suivant:

BOOL est typedef int.

GetString(10,'a'); // compiler get confused in resolving the function 

si «a» doit être converti en BOOL ou chaîne ???

Lorsque vous effectuez un appel de fonction, donnez l'argument approprié en utilisant static_cast pour rendre la fonction désirée à appeler.

char ch = 'a'; 
GetString(10,static_cast<BOOL>(ch)); // calls function with 2nd argument as BOOL 

GetString(10,static_cast<string>(ch)); //calls function with 2nd argument as string 
2
GetInput(13, FALSE, 30 * 10); 

Je pense que

FALSE ==> o ==> NULL is getting converted to std::string(NULL) 

Par conséquent, il ne peut pas déterminer la méthode à instancier.

T0 prouver ce contrôle ceci:

GetInput(13, TRUE, 30 * 10); // il fonctionne

+0

Juste le simple fait que 'FALSE' est convertible en' std :: string' ne fera pas échouer ce code. La première version de la fonction a un deuxième argument de type 'BOOL', qui correspond mieux à' FALSE' qu'à 'std :: string'. Le problème, comme je l'ai dit dans ma réponse, est différent. Le problème est causé par le troisième argument: '30 * 10'. Il doit avoir un type * unsigned * pour que la première fonction gagne la résolution de surcharge. – AnT