ambiguo string :: operator = chiamata per il tipo con la conversione implicita a int e la stringa

Question

Dato il seguente programma:

#include <iostream> 
#include <string> 
using namespace std; 
struct GenericType{ 
    operator string(){ 
     return "Hello World"; 
    } 
    operator int(){ 
     return 111; 
    } 
    operator double(){ 
     return 123.4; 
    } 
}; 
int main(){ 
    int i = GenericType(); 
    string s = GenericType(); 
    double d = GenericType(); 
    cout << i << s << d << endl; 
    i = GenericType(); 
    s = GenericType(); //This is the troublesome line 
    d = GenericType(); 
    cout << i << s << d << endl; 
} 

Compila il Visual Studio 11, ma non clang o gcc. E sta avendo difficoltà perché vuole convertire in modo implicito da un GenericType a un int ad un char ma potrebbe anche restituire un string e quindi v'è un'ambiguità (operator=(char) e operator=(string) sia partita GenericType).

Tuttavia, il costruttore di copie funziona correttamente.

La mia domanda è: come posso risolvere questa ambiguità senza modificare il contenuto di main? Cosa devo fare per modificare GenericType per gestire questa situazione?

Answer 1

Credo che gcc e clang siano corretti.

Ci sono due operator= sovraccarichi in gioco:

string& operator=(string const& str); // (1) 
string& operator=(char ch);   // (2) 

Entrambe queste operator= sovraccarichi richiedono una conversione definita dall'utente dal proprio argomento di tipo GenericType. (1) richiede l'utilizzo della conversione in string. (2) richiede l'utilizzo della conversione in int, seguita da una conversione standard in char.

L'importante è che entrambi i sovraccarichi richiedano una conversione definita dall'utente. Per determinare se una di queste conversioni è migliore rispetto agli altri, possiamo guardare alle regole di risoluzione di sovraccarico, in particolare la seguente regola da C++ 11 §13.3.3.2/3 (riformattato per chiarezza):

utente -defined sequenza conversione U1 è una migliore sequenza conversione di un'altra sequenza di conversione definita dall'utente U2 se

1. che contengono la stessa funzione definita dall'utente conversione o costruttore o inizializzazione aggregata e

2. la seconda sequenza di conversione standard di U1 è migliore della seconda sequenza di conversione standard di U2.

Nota che un e unisce le due parti della norma, in modo da entrambe le parti devono essere soddisfatti. La prima parte della regola non è soddisfatta: le due sequenze di conversione definite dall'utente utilizzano diverse funzioni di conversione definite dall'utente.

Pertanto, nessuna conversione è migliore e la chiamata è ambigua.

[Non ho un buon suggerimento su come risolvere il problema senza cambiare la definizione di main(). Le conversioni implicite di solito non sono una buona idea; a volte sono molto utili, ma più frequentemente possono causare ambiguità di sovraccarico o altri strani comportamenti di sovraccarico.]

c'era un bug report gcc in cui questo problema è stato descritto e risolto come da disegno: compiler incorrectly diagnoses ambigous operator overload.

Answer 2

Credo GCC è sbagliato. Nel libro "The C++ Programming Language" di Bjarne Stroustrup, c'è un intero capitolo dedicato al sovraccarico dell'operatore. Nella sezione 11.4.1, il primo paragrafo dice questo:

"Un'assegnazione di un valore di tipo V a un oggetto di classe X è legale se esiste un operatore di assegnazione X :: operator = (Z) in modo che V è Z o c'è una conversione univoca da V a Z. L'inizializzazione è trattata in modo equivalente. "

Nell'esempio, GCC accetta "string s = GenericType();" tuttavia rifiuta "s = GenericType();", quindi ovviamente non tratta il compito allo stesso modo dell'inizializzazione. Questo è stato il mio primo indizio che qualcosa non va nel GCC.

GCC riporta 3 candidati per la conversione di GenericType in stringa nell'assegnazione, il tutto in basic_string.h. Uno è la conversione corretta, uno che segnala non è valido, e il terzo causa l'ambiguità. Questo è il sovraccarico del operatore basic_string.h che causa l'ambiguità:

/** 
* @brief Set value to string of length 1. 
* @param c Source character. 
* 
* Assigning to a character makes this string length 1 and 
* (*this)[0] == @a c. 
*/ 
basic_string& operator=(_CharT __c) { 
    this->assign(1, __c); 
    return *this; 
} 

questa non è una conversione valida perché accetta un operando che non corrisponde al tipo di oggetto che viene passato a esso. In nessun posto si tratta di un incarico a un personaggio tentato, quindi questa conversione non dovrebbe essere un candidato per niente meno che causa ambiguità. Sembra che GCC mischi il tipo di modello con il tipo di operando nel suo membro.

EDIT: Non ero consapevole del fatto che l'assegnazione di un intero in una stringa era infatti legale, come un intero può essere convertito in un char, che può essere assegnato ad una stringa (anche se una stringa non può essere inizializzata a un salmerino!). GenericType definisce una conversione in un int, rendendo così questo membro un candidato valido. Tuttavia, continuo a sostenere che non si tratta di una conversione valida, poiché l'utilizzo di questa conversione comporterebbe due conversioni implicite definite dall'utente per l'assegnazione, prima da GenericType a int, quindi da Int a String. Come affermato nello stesso libro 11.4.1, "solo un livello di conversione implicita definita dall'utente è legale."

Answer 3

La mia domanda è: come posso risolvere questa ambiguità senza modificare il contenuto di main?

creare una classe denominata string che non dispone di un ambiguo operator= e poi non lo fanno using il std uno.

Ovviamente questa non è una soluzione molto buona, ma funziona e non è necessario modificare main.

Non penso che si possa ottenere il comportamento desiderato in un altro modo.