Fare affidamento sulla conversione implicita di argomenti è considerato pericoloso?

C ++ ha una funzione (non riesco a capirne il nome proprio), che chiama automaticamente costruttori corrispondenti di tipi di parametri se i tipi di argomento non sono quelli previsti.

Un esempio molto semplice di ciò è chiamare una funzione che prevede un std::stringcon un const char*argomento. Il compilatore genererà automaticamente il codice per invocare il std::stringcostruttore appropriato .

Mi chiedo, è male per la leggibilità come penso che sia?

Ecco un esempio:

class Texture {
public:
    Texture(const std::string& imageFile);
};

class Renderer {
public:
    void Draw(const Texture& texture);
};

Renderer renderer;
std::string path = "foo.png";
renderer.Draw(path);

Va bene? O va troppo lontano? Se non dovessi farlo, posso in qualche modo far avvisare Clang o GCC?

Questo è indicato come costruttore di conversione (o talvolta costruttore implicito o conversione implicita).

Non sono a conoscenza di un passaggio di compilazione per avvisare quando ciò si verifica, ma è molto facile da prevenire; basta usare la explicitparola chiave.

class Texture {
public:
    explicit Texture(const std::string& imageFile);
};

Per sapere se convertire i costruttori è una buona idea: dipende.

Circostanze in cui la conversione implicita ha senso:

• La classe è abbastanza economica da costruire che non ti importa se è implicitamente costruita.
• Alcune classi sono concettualmente simili ai loro argomenti (come std::stringriflettere lo stesso concetto dal const char *quale può implicitamente convertirsi), quindi la conversione implicita ha senso.
• Alcune classi diventano molto più spiacevoli da usare se la conversione implicita è disabilitata. (Pensa di dover invocare esplicitamente std :: string ogni volta che vuoi passare letteralmente una stringa. Parti di Boost sono simili.)

Circostanze in cui la conversione implicita ha meno senso:

• La costruzione è costosa (come l'esempio di Texture, che richiede il caricamento e l'analisi di un file grafico).
• Le lezioni sono concettualmente molto diverse dalle loro argomentazioni. Considera, ad esempio, un contenitore simile a un array che assume le sue dimensioni come argomento:

    class FlagList
    {
        FlagList (int initial_size); 
    };

    void SetFlags (const FlagList & flag_list);

    int main () {
        // Ora questo viene compilato, anche se non è affatto ovvio
        // cosa sta facendo.
        SetFlags (42);
    }

• La costruzione potrebbe avere effetti collaterali indesiderati. Ad esempio, una AnsiStringclasse non dovrebbe essere implicitamente costruita da a UnicodeString, poiché la conversione da Unicode a ANSI potrebbe perdere informazioni.

Ulteriori letture:

• Le domande frequenti su C ++ sui costruttori espliciti
• La Guida allo stile di Google C ++ afferma di usare quasi sempre costruttori espliciti.
• Questa domanda StackOverflow riguarda più pro e contro.

Questo è più un commento che una risposta ma troppo grande per inserire un commento.

È interessante notare g++che non mi permette di farlo:

#include <iostream>
#include <string>

class Texture {
        public:
                Texture(const std::string& imageFile)
                {
                        std::cout << "Texture()" << std::endl;
                }
};

class Renderer {
        public:
                void Draw(const Texture& texture)
                {
                        std::cout << "Renderer.Draw()" << std::endl;
                }
};

int main(int argc, char* argv[])
{
        Renderer renderer;
        renderer.Draw("foo.png");

        return 0;
}

Produce quanto segue:

$ g++ -o Conversion.exe Conversion.cpp 
Conversion.cpp: In function ‘int main(int, char**)’:
Conversion.cpp:23:25: error: no matching function for call to ‘Renderer::Draw(const char [8])’
Conversion.cpp:14:8: note: candidate is: void Renderer::Draw(const Texture&)

Tuttavia, se cambio la riga in:

   renderer.Draw(std::string("foo.png"));

Eseguirà quella conversione.

Si chiama conversione di tipo implicito. In generale è una buona cosa, in quanto inibisce inutili ripetizioni. Ad esempio, ottieni automaticamente una std::stringversione di Drawsenza dover scrivere alcun codice aggiuntivo per esso. Può anche aiutare a seguire il principio aperto-chiuso, in quanto consente di estendere Rendererle capacità senza modificarsi Renderer.

D'altra parte, non è privo di inconvenienti. Può essere difficile capire da dove provenga una discussione, per prima cosa. A volte può produrre risultati imprevisti in altri casi. Ecco a cosa explicitserve la parola chiave. Se lo metti sul Texturecostruttore disabilita l'uso di quel costruttore per la conversione di tipo implicita. Non sono a conoscenza di un metodo per mettere in guardia a livello globale sulla conversione di tipo implicita, ma ciò non significa che un metodo non esista, solo che gcc ha un numero incomprensibilmente grande di opzioni.