2010-05-12 8 views
5

Ambiente: VS2005 C++ utilizzando STLPort 5.1.4.std :: metodo di inserimento stringa ha sovraccarichi ambigui?

compilazione del seguente frammento di codice:

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

visualizzato un errore:

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

Sembra che il problema è il metodo chiamata inserto sull'oggetto stringa.

I due overload definiti sono

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

Ma dato che STLPort utilizza un semplice char * come iteratore, il letterale zero nel metodo di inserimento nel mio codice è ambigua.

Così, mentre io posso facilmente superare il problema da accennando come

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

La mia domanda è: è questo sovraccarico e possibili ambiguità intenzionale nella specifica? O più probabilmente un indesiderato effetto collaterale della specifica implementazione STLPort?

(Si noti che lo STL fornito da Microsoft non ha questo problema in quanto ha una classe per l'iteratore, al posto di un puntatore nudo)

+0

Per essere più rigorosa: dovrebbe essere 'copied.insert (static_cast (0), static_cast (1), ch)' – ereOn

+0

@ereOn: Il secondo 'static_cast' non è necessaria dal momento che entrambi i sovraccarichi prendono un' size_t' come secondo parametro. –

+1

Non necessario a causa di possibili sovraccarichi futuri e del tipo integrale incerto di "1". – Marius

risposta

0

Se a distinguere il tipo di differenti numeri interi, non c'è ambiguità a tutto. comandi

Buone pratiche per memorizzare le dimensioni del buffer in size_t (o ssize_t) tipi, non int.

Se siete d'accordo, chiamare insert(int, int, char) non ha senso dato che i primi due argomenti dovrebbero essere "buffer size".

Se non è stata effettuata alcuna conversione implicita da int a size_t, non è possibile chiamare anche insert() in questo modo.

0

Intenzionale o meno, il problema ha più a che fare con la semantica di 0 rispetto alle funzioni membro in questione. Forse i progettisti della biblioteca Microsoft (hanno usato Dinkumware l'ultima volta che ho controllato) erano più cauti in questo senso.

+0

Dinkumware probabilmente non ha questo problema: l'uso di veri iteratori allevia l'ambiguità. –

Problemi correlati