C'è un aspetto negativo nella dichiarazione di variabili con auto in C ++?

Sembra che sia autostata aggiunta una caratteristica abbastanza significativa in C ++ 11 che sembra seguire molti dei linguaggi più recenti. Come in un linguaggio come Python, non ho visto alcuna dichiarazione esplicita di variabili (non sono sicuro che sia possibile utilizzare gli standard Python).

C'è un inconveniente nell'usare autoper dichiarare le variabili invece di dichiararle esplicitamente?

Mi hai solo chiesto degli svantaggi, quindi ne sto evidenziando alcuni. Se usato bene, autoha anche diversi vantaggi. Gli svantaggi derivano dalla facilità di abuso e dall'aumento del potenziale per il codice di comportarsi in modo non intenzionale.

Lo svantaggio principale è che, utilizzando auto, non si conosce necessariamente il tipo di oggetto che viene creato. Ci sono anche occasioni in cui il programmatore potrebbe aspettarsi che il compilatore deduca un tipo, ma il compilatore ne deduce categoricamente un altro.

Data una dichiarazione simile

auto result = CallSomeFunction(x,y,z);

non hai necessariamente conoscenza di che tipo resultsia. Potrebbe essere un int. Potrebbe essere un puntatore. Potrebbe essere qualcos'altro. Tutti supportano diverse operazioni. Puoi anche cambiare radicalmente il codice con una piccola modifica come

auto result = CallSomeFunction(a,y,z);

perché, a seconda di quali sovraccarichi esistono per CallSomeFunction()il tipo di risultato, potrebbe essere completamente diverso - e quindi il codice successivo potrebbe comportarsi in modo completamente diverso da quello previsto. Potresti innescare improvvisamente messaggi di errore nel codice successivo (ad es. Successivamente tentando di dereferenziare un int, cercando di cambiare qualcosa che è ora const). Il cambiamento più sinistro è il punto in cui la modifica passa oltre il compilatore, ma il codice successivo si comporta in modi diversi e sconosciuti, possibilmente con errori.

Non avere una conoscenza esplicita del tipo di alcune variabili rende quindi più difficile giustificare rigorosamente l'affermazione che il codice funziona come previsto. Ciò significa maggiori sforzi per giustificare le affermazioni di "idoneità allo scopo" in settori ad alta criticità (ad esempio critici per la sicurezza o mission-critical).

L'altro, svantaggio più comune, è la tentazione per un programmatore di utilizzare autocome strumento contundente per forzare la compilazione del codice, piuttosto che pensare a cosa sta facendo il codice e lavorare per farlo correttamente.

Questo non è autoesattamente uno svantaggio di principio, ma in termini pratici sembra essere un problema per alcuni. Fondamentalmente, alcune persone: a) trattano autocome un salvatore per i tipi e chiudono il cervello quando lo usano, oppure b) dimenticano che autosi deduce sempre ai tipi di valore. Questo fa sì che le persone facciano cose del genere:

auto x = my_obj.method_that_returns_reference();

Spiacenti, abbiamo appena copiato in profondità un oggetto. Spesso è un errore o un fallimento delle prestazioni. Quindi, puoi anche oscillare dall'altra parte:

const auto& stuff = *func_that_returns_unique_ptr();

Ora ottieni un riferimento penzolante. Questi problemi non sono affatto causati da auto, quindi non li considero argomenti legittimi contro di esso. Ma sembra autorendere questi problemi più comuni (per esperienza personale), per i motivi che ho elencato all'inizio.

Penso che, dato il tempo, le persone si adegueranno e comprenderanno la divisione del lavoro: ne autodeduce il tipo sottostante, ma tu vuoi ancora pensare a riferimento e costanza. Ma ci vuole un po 'di tempo.

Altre risposte citano inconvenienti come "non sai davvero quale sia il tipo di una variabile". Direi che questo è in gran parte correlato alla convenzione di denominazione sciatta nel codice. Se le tue interfacce hanno un nome chiaro, non dovresti preoccuparti di quale sia il tipo esatto. Certo, auto result = callSomeFunction(a, b);non ti dice molto. Ma auto valid = isValid(xmlFile, schema);ti dice abbastanza da usare validsenza preoccuparti del tipo esatto. Dopotutto, con just if (callSomeFunction(a, b)), non sapresti nemmeno il tipo. Lo stesso con qualsiasi altro oggetto temporaneo di sottoespressione. Quindi non lo considero un vero inconveniente di auto.

Direi che il suo principale svantaggio è che a volte il tipo esatto di restituzione non è quello con cui vuoi lavorare. In effetti, a volte il tipo restituito effettivo differisce dal tipo restituito "logico" come dettaglio di implementazione / ottimizzazione. I modelli di espressione sono un ottimo esempio. Diciamo che abbiamo questo:

SomeType operator* (const Matrix &lhs, const Vector &rhs);

Logicamente, ci aspetteremmo SomeTypedi esserlo Vectore vorremmo sicuramente trattarlo come tale nel nostro codice. Tuttavia, è possibile che ai fini dell'ottimizzazione, la libreria di algebra che stiamo utilizzando implementa i modelli di espressione e il tipo di ritorno effettivo è questo:

MultExpression<Matrix, Vector> operator* (const Matrix &lhs, const Vector &rhs);

Ora, il problema è che MultExpression<Matrix, Vector>con ogni probabilità verrà archiviato un const Matrix&e const Vector&internamente; si aspetta che si convertirà in a Vectorprima della fine della sua espressione completa. Se abbiamo questo codice, va tutto bene:

extern Matrix a, b, c;
extern Vector v;

void compute()
{
  Vector res = a * (b * (c * v));
  // do something with res
}

Tuttavia, se avessimo usato autoqui, potremmo avere dei problemi:

void compute()
{
  auto res = a * (b * (c * v));
  // Oops! Now `res` is referring to temporaries (such as (c * v)) which no longer exist
}

Uno degli svantaggi è che a volte non è possibile dichiarare const_iteratorcon auto. Otterrai un iteratore ordinario (non const) in questo esempio di codice preso da questa domanda :

map<string,int> usa;
//...init usa
auto city_it = usa.find("New York");

Rende il tuo codice un po 'più difficile o noioso da leggere. Immagina qualcosa del genere:

auto output = doSomethingWithData(variables);

Ora, per capire il tipo di output, dovresti rintracciare la firma della doSomethingWithDatafunzione.

Come questo sviluppatore, odio auto. O meglio, odio il modo in cui le persone abusano auto.

Sono del (forte) parere che autoè per aiutare a scrivere codice generico, non per ridurre la digitazione .
Il C ++ è un linguaggio il cui obiettivo è farti scrivere codice robusto, non minimizzare i tempi di sviluppo.
Ciò è abbastanza ovvio da molte funzionalità di C ++, ma sfortunatamente alcune di quelle più recenti come autoquella riducono la digitazione inducono le persone a pensare che dovrebbero iniziare a essere pigri con la digitazione.

In pre- autogiorni, la gente typedefs, che era fantastico, perché typedef ha permesso il progettista della biblioteca per aiutarti a capire quale sia il tipo di ritorno dovrebbe essere, in modo che le loro opere della biblioteca come previsto. Quando lo usi auto, togli il controllo al progettista della classe e chiedi invece al compilatore di capire quale dovrebbe essere il tipo, il che rimuove uno dei più potenti strumenti C ++ dalla casella degli strumenti e rischia di rompere il loro codice.

Generalmente, se lo usi auto, dovrebbe essere perché il tuo codice funziona per qualsiasi tipo ragionevole , non perché sei troppo pigro per scrivere il tipo con cui dovrebbe funzionare. Se utilizzi autocome strumento per aiutare la pigrizia, ciò che accade è che alla fine inizi a introdurre bug sottili nel tuo programma, di solito causati da conversioni implicite che non sono avvenute perché hai usato auto.

Sfortunatamente, questi bug sono difficili da illustrare in un breve esempio qui perché la loro brevità li rende meno convincenti rispetto agli esempi reali che emergono in un progetto utente - tuttavia, si verificano facilmente in un codice pesante di template che si aspetta che alcune conversioni implicite prendano posto.

Se vuoi un esempio, ce n'è uno qui . Un piccolo appunto, però: prima di essere tentati di saltare e criticare il codice: tieni presente che molte librerie ben note e mature sono state sviluppate attorno a conversioni così implicite e sono lì perché risolvono problemi che possono essere difficili se non impossibili per risolvere diversamente. Prova a trovare una soluzione migliore prima di criticarli.

autonon ha di per sé degli inconvenienti e io sostengo (agitando a mano) di usarlo ovunque nel nuovo codice. Consente al codice di controllare costantemente il tipo e di evitare costantemente lo slicing silenzioso. (Se Bderiva Ae una funzione che ritorna Aimprovvisamente ritorna B, si autocomporta come previsto per memorizzare il suo valore di ritorno)

Tuttavia, il codice precedente pre-C ++ 11 può fare affidamento su conversioni implicite indotte dall'uso di variabili tipizzate in modo esplicito. La modifica di una variabile esplicitamente digitata in autopotrebbe cambiare il comportamento del codice , quindi è meglio essere cauti.

La parola chiave autosemplicemente deduce il tipo dal valore restituito. Pertanto, non è equivalente a un oggetto Python, ad es

# Python
a
a = 10       # OK
a = "10"     # OK
a = ClassA() # OK

// C++
auto a;      // Unable to deduce variable a
auto a = 10; // OK
a = "10";    // Value of const char* can't be assigned to int
a = ClassA{} // Value of ClassA can't be assigned to int
a = 10.0;    // OK, implicit casting warning

Poiché autoviene dedotto durante la compilazione, non avrà alcun inconveniente durante l'esecuzione.

Ciò che nessuno ha menzionato qui finora, ma per sé merita una risposta se me lo chiedessi.

Poiché (anche se tutti dovrebbero essere consapevoli del fatto C != C++) il codice scritto in C può essere facilmente progettato per fornire una base per il codice C ++ e quindi essere progettato senza troppi sforzi per essere compatibile con C ++, questo potrebbe essere un requisito per la progettazione.

Conosco alcune regole da cui alcuni costrutti ben definiti Cnon sono validi per C++e viceversa. Ma ciò si tradurrebbe semplicemente in eseguibili rotti e si applica la clausola UB nota che la maggior parte delle volte viene notata da strani loop che causano arresti anomali o altro (o possono anche non essere rilevati, ma non importa qui).

Ma autoè la prima volta ¹ questo cambia!

Immagina di aver usato prima autocome identificatore della classe di archiviazione e di trasferire il codice. Non si spezzerebbe nemmeno necessariamente (a seconda del modo in cui è stato usato); in realtà potrebbe cambiare silenziosamente il comportamento del programma.

È qualcosa che dovresti tenere a mente.

¹ _{Almeno la prima volta che ne sono a conoscenza.}

Una ragione a cui riesco a pensare è che perdi l'opportunità di forzare la classe che viene restituita. Se la tua funzione o metodo ha restituito un lungo 64 bit e volevi solo 32 int senza segno, perdi l'opportunità di controllarlo.

Come ho descritto in questa risposta, a auto volte può risultare in situazioni funky che non intendevi. Devi dire esplicitamente auto&di avere un tipo di riferimento mentre semplicemente autopuoi creare un tipo di puntatore. Ciò può causare confusione omettendo lo specificatore tutti insieme, risultando in una copia del riferimento anziché in un riferimento effettivo.

Un altro esempio irritante:

for (auto i = 0; i < s.size(); ++i)

genera un avviso ( comparison between signed and unsigned integer expressions [-Wsign-compare]), poiché iè un int firmato. Per evitare ciò è necessario scrivere ad es

for (auto i = 0U; i < s.size(); ++i)

o forse meglio:

for (auto i = 0ULL; i < s.size(); ++i)

Penso che autosia buono se usato in un contesto localizzato, in cui il lettore può facilmente e ovviamente dedurre il suo tipo, o ben documentato con un commento del suo tipo o un nome che inferisce il tipo reale. Chi non capisce come funziona potrebbe prenderlo nel modo sbagliato, come usarlo al posto di templateo simile. Ecco alcuni casi positivi e negativi secondo me.

void test (const int & a)
{
    // b is not const
    // b is not a reference

    auto b = a;

    // b type is decided by the compiler based on value of a
    // a is int
}

Buoni usi

iteratori

std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int> v();

..

std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int>::iterator it = v.begin();

// VS

auto vi = v.begin();

Puntatori di funzioni

int test (ClassWithLongName1 a, ClassWithLongName2 b, int c)
{
    ..
}

..

int (*fp)(ClassWithLongName1, ClassWithLongName2, int) = test;

// VS

auto *f = test;

Usi sbagliati

Flusso di dati

auto input = "";

..

auto output = test(input);

Firma della funzione

auto test (auto a, auto b, auto c)
{
    ..
}

Casi di prova

for(auto i = 0; i < 100; i++)
{
    ..
}

Sono sorpreso che nessuno l'abbia menzionato, ma supponiamo che tu stia calcolando il fattoriale di qualcosa:

#include <iostream>
using namespace std;

int main() {
    auto n = 40;
    auto factorial = 1;

    for(int i = 1; i <=n; ++i)
    {
        factorial *= i;
    }

    cout << "Factorial of " << n << " = " << factorial <<endl;   
    cout << "Size of factorial: " << sizeof(factorial) << endl; 
    return 0;
}

Questo codice genererà questo:

Factorial of 40 = 0
Size of factorial: 4

Quello non era sicuramente il risultato atteso. Ciò è accaduto perché autodedotto il tipo di variabile fattoriale come intperché assegnato 1.