2010-05-12 10 views
5

Environnement: VS2005 C++ utilisant STLPort 5.1.4.La méthode std :: string insert a des surcharges ambiguës?

Compiler le code suivant:

std::string copied = "asdf"; 
char ch = 's'; 
copied.insert(0,1,ch); 

Je reçois une erreur:

Error 1 error C2668: 'stlpx_std::basic_string<_CharT,_Traits,_Alloc>::insert' : ambiguous call to overloaded function 

Il semble que le problème est l'appel de méthode d'insertion sur l'objet chaîne.

Les deux sont définis les surcharges

void insert (iterator p, size_t n, char c); 
string& insert (size_t pos1, size_t n, char c); 

Mais étant donné que STLPort utilise un simple char * comme iterator, le zéro littéral dans la méthode d'insertion dans mon code est ambigu.

Ainsi, alors que je peux facilement résoudre le problème en faisant allusion tels que

copied.insert(size_t(0),1,ch); 

Ma question est la suivante: est-ce possible surcharge et de l'ambiguïté intentionnelle dans le cahier des charges? Ou plus probablement un effet secondaire involontaire de la mise en œuvre de STLPort spécifique?

(Notez que le TSL fourni par Microsoft n'a pas ce problème car il a une classe pour la iterator, au lieu d'un pointeur nu)

+0

Pour être plus stricte: il devrait être 'copied.insert (static_cast (0), static_cast (1), ch)' – ereOn

+0

@ereOn: La deuxième 'static_cast' est inutile puisque les deux prennent une' surcharge size_t' comme deuxième paramètre. –

+1

Non inutile en raison d'éventuelles surcharges futures et du type intégral incertain de '1'. – Marius

Répondre

0

Si vous différenciez les différents types d'entiers, il n'y a pas d'ambiguïté à all.

Bonnes pratiques pour stocker les tailles de tampon dans les types size_t (ou ssize_t), et non int.

Si vous êtes d'accord avec cela, appeler insert(int, int, char) n'a aucun sens puisque les deux premiers arguments sont supposés être des "tailles de tampon".

S'il n'y avait pas de conversion implicite de int en size_t, vous ne pourriez même pas appeler insert() de cette façon.

0

Intentional ou pas, le problème a plus à voir avec la sémantique de 0 qu'avec les fonctions membres en question. Peut-être que les concepteurs de la bibliothèque Microsoft (ils ont utilisé Dinkumware la dernière fois que j'ai vérifié) étaient plus prudents à cet égard.

+0

Dinkumware n'aurait probablement pas ce problème: l'utilisation de vrais itérateurs atténue l'ambiguïté. –