vector :: at vs. vector :: operator []

So che at()è più lento che a []causa del controllo dei confini, che è anche discusso in domande simili come C ++ Vector at / [] operator speed o :: std :: vector :: at () vs operator [] << risultati sorprendenti !! Da 5 a 10 volte più lento / veloce! . Semplicemente non capisco a cosa at()serve il metodo.

Se ho un vettore semplice come questo: std::vector<int> v(10);e decido di accedere ai suoi elementi usando at()invece che []in situazioni in cui ho un indice ie non sono sicuro che sia nei limiti dei vettori, mi costringe a avvolgerlo con try-catch blocco :

try
{
    v.at(i) = 2;
}
catch (std::out_of_range& oor)
{
    ...
}

anche se sono in grado di ottenere lo stesso comportamento utilizzando size()e controllando l'indice da solo, il che sembra più facile e molto conveniente per me:

if (i < v.size())
    v[i] = 2;

Quindi la mia domanda è:
quali sono i vantaggi dell'utilizzo di vector :: at over vector :: operator [] ?
Quando dovrei usare vector :: at anziché vector :: size + vector :: operator [] ?

Direi che le eccezioni che vector::at()genera non sono realmente destinate ad essere catturate dal codice immediatamente circostante. Sono utili principalmente per rilevare bug nel codice. Se è necessario controllare i limiti in fase di esecuzione perché ad esempio l'indice proviene dall'input dell'utente, è davvero meglio con ifun'istruzione. Quindi, in sintesi, progetta il tuo codice con l'intenzione che vector::at()non genererà mai un'eccezione, in modo che se lo fa e il tuo programma si interrompe, è un segno di un bug. (proprio come un assert())

mi costringe a avvolgerlo con il blocco try-catch

No, non è così (il blocco try / catch può essere a monte). È utile quando si desidera che venga lanciata un'eccezione piuttosto che il programma per entrare nel regno del comportamento indefinito.

Sono d'accordo che la maggior parte degli accessi fuori limite ai vettori sono un errore del programmatore (nel qual caso dovresti usarli assertper individuare quegli errori più facilmente; la maggior parte delle versioni di debug delle librerie standard lo fa automaticamente per te). Non vuoi usare eccezioni che possono essere inghiottite a monte per segnalare errori del programmatore: vuoi essere in grado di correggere il bug .

Poiché è improbabile che un accesso fuori limite a un vettore faccia parte del normale flusso del programma (nel caso lo sia, hai ragione: controlla in anticipo sizeinvece di lasciare che l'eccezione si manifesti), sono d'accordo con la tua diagnostica: atè essenzialmente inutile.

Quali sono i vantaggi nell'usare vector :: at rispetto a vector :: operator []? Quando dovrei usare vector :: at anziché vector :: size + vector :: operator []?

Il punto importante qui è che le eccezioni consentono la separazione del normale flusso di codice dalla logica di gestione degli errori e un singolo blocco catch può gestire i problemi generati da una miriade di siti di lancio, anche se disseminati in profondità all'interno delle chiamate di funzione. Quindi, non at()è necessariamente più facile per un singolo utilizzo, ma a volte diventa più facile - e meno offuscamento della logica del caso normale - quando hai molte indicizzazioni da convalidare.

È anche degno di nota il fatto che in alcuni tipi di codice un indice viene incrementato in modi complessi e utilizzato continuamente per cercare un array. In questi casi, è molto più facile garantire controlli corretti utilizzando at().

Come esempio del mondo reale, ho codice che tokenizza C ++ in elementi lessicali, quindi altro codice che sposta un indice sul vettore di token. A seconda di ciò che si incontra, potrei voler incrementare e controllare l'elemento successivo, come in:

if (token.at(i) == Token::Keyword_Enum)
{
    ASSERT_EQ(tokens.at(++i), Token::Idn);
    if (tokens.at(++i) == Left_Brace)
        ...
    or whatever

In questo tipo di situazione, è molto difficile controllare se hai raggiunto in modo inappropriato la fine dell'input perché dipende molto dagli esatti token incontrati. Il controllo esplicito in ogni punto di utilizzo è doloroso e c'è molto più spazio per gli errori del programmatore poiché aumenti pre / post, offset al punto di utilizzo, ragionamento errato sulla validità continua di alcuni test precedenti ecc.

at può essere più chiaro se hai un puntatore al vettore:

return pVector->at(n);
return (*pVector)[n];
return pVector->operator[](n);

Prestazioni a parte, il primo di questi è il codice più semplice e chiaro.

Innanzitutto, non viene specificato se at()o operator[]è più lento. Quando non ci sono errori di limite, mi aspetto che abbiano all'incirca la stessa velocità, almeno nel debug delle build. La differenza è che at()specifica esattamente cosa accadrà in presenza di un errore di limite (un'eccezione), dove come nel caso di operator[], è un comportamento indefinito: un arresto anomalo in tutti i sistemi che uso (g ++ e VC ++), almeno quando vengono utilizzati i normali flag di debug. (Un'altra differenza è che una volta che sono sicuro del mio codice, posso ottenere un aumento sostanziale della velocità operator[] disattivando il debug. Se le prestazioni lo richiedono, non lo farei a meno che non fosse necessario.)

In pratica, at()è raramente appropriato. Se il contesto è tale che sai che l'indice potrebbe non essere valido, probabilmente vuoi il test esplicito (ad esempio per restituire un valore predefinito o qualcosa del genere), e se sai che non può essere non valido, vuoi interrompere (e se non sai se può essere non valido o meno, ti suggerisco di specificare più precisamente l'interfaccia della tua funzione). Esistono alcune eccezioni, tuttavia, in cui l'indice non valido può derivare dall'analisi dei dati dell'utente e l'errore dovrebbe causare l'interruzione dell'intera richiesta (ma non arrestare il server); in questi casi, un'eccezione è appropriata e at()lo farà per te.

Il punto centrale dell'utilizzo delle eccezioni è che il codice di gestione degli errori può essere più lontano.

In questo caso specifico, l'input dell'utente è davvero un buon esempio. Immagina di voler analizzare semanticamente una struttura dati XML che utilizza indici per fare riferimento a un tipo di risorsa che memorizzi internamente in un file std::vector. Ora l'albero XML è un albero, quindi probabilmente vorrai usare la ricorsione per analizzarlo. In fondo, nella ricorsione, potrebbe esserci una violazione di accesso da parte del writer del file XML. In tal caso, di solito vuoi superare tutti i livelli di ricorsione e rifiutare semplicemente l'intero file (o qualsiasi tipo di struttura "più grossolana"). È qui che torna utile. Puoi semplicemente scrivere il codice di analisi come se il file fosse valido. Il codice della libreria si occuperà del rilevamento degli errori e tu puoi semplicemente catturare l'errore a livello grossolano.

Inoltre, altri contenitori, come std::map, hanno anche una std::map::atsemantica leggermente diversa da std::map::operator[]: at può essere utilizzato su una mappa const, mentre operator[]non può. Ora, se volessi scrivere codice agnostico del contenitore, come qualcosa che potrebbe occuparsi di const std::vector<T>&o const std::map<std::size_t, T>&, ContainerType::atsarebbe la tua arma preferita.

Tuttavia, tutti questi casi di solito si verificano quando si gestisce una sorta di input di dati non convalidato. Se sei sicuro del tuo intervallo valido, come normalmente dovresti essere, di solito puoi usare operator[], ma meglio ancora, iteratori con begin()e end().

Secondo questo articolo, prestazioni a parte, non fa alcuna differenza da utilizzare ato operator[], solo se l'accesso è garantito entro le dimensioni del vettore. Altrimenti, se l'accesso è basato solo sulla capacità del vettore, è più sicuro da usare at.

Nota: sembra che alcune nuove persone stiano votando negativamente questa risposta senza avere la cortesia di dire cosa non va. La risposta di seguito è corretta e può essere verificata qui .

C'è davvero solo una differenza: atcontrolla i limiti mentre operator[]no. Questo vale sia per le build di debug che per le build di rilascio e questo è molto ben specificato dagli standard. È così semplice.

Questo rende atun metodo più lento, ma è anche un pessimo consiglio da non usare at. Devi guardare i numeri assoluti, non i numeri relativi. Posso tranquillamente scommettere che la maggior parte del tuo codice sta facendo operazioni più costose di at. Personalmente, cerco di usare atperché non voglio che un brutto bug crei comportamenti indefiniti e si intrufoli nella produzione.