vector :: al vs. vector :: operator []

Question

So che at() è più lento di [] a causa del suo controllo di confine, che è anche discusso in questioni simili, come C++ Vector at/[] operator speed o ::std::vector::at() vs operator[] << surprising results!! 5 to 10 times slower/faster!. Semplicemente non capisco per cosa sia utile il metodo at().

Se ho un semplice vettore come questo: std::vector<int> v(10); e decido di accedere ai suoi elementi utilizzando at() invece di [] nella situazione in cui ho un indice di i e non sono sicuro se i suoi limiti in vettori, forza mi avvolgerlo con blocco try-catch:

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

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

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

Quindi la mia domanda è:
Quali sono i vantaggi di utilizzare vector::at sopra vector::operator[]?
Quando è necessario utilizzare vector::at anziché vector::size + vector::operator[]?

Answer 1

direi che le eccezioni che vector::at() tiri non sono realmente destinati ad essere catturato dal codice immediatamente circostante. Sono principalmente utili per catturare bug nel tuo codice. Se è necessario il controllo dei limiti in fase di esecuzione, ad es. l'indice proviene dall'input dell'utente, è davvero meglio con una dichiarazione if. Quindi, in sintesi, progetta il tuo codice con l'intenzione che vector::at() non genererà mai un'eccezione, così che se lo fa, e il tuo programma si interrompe, è un segno di un bug. (proprio come un assert())

Answer 2

mi costringe a avvolgerlo con blocco try-catch

No, non (blocco try/catch può essere a monte). È utile quando vuoi che venga lanciata un'eccezione piuttosto che il tuo programma per entrare nel regno del comportamento non definito.

Sono d'accordo che la maggior parte fuori dai limiti accessi ai vettori sono l'errore di un programmatore (nel qual caso si dovrebbe usare assert per individuare quegli errori più facilmente; la maggior parte delle versioni di debug delle librerie standard di farlo automaticamente per voi). Non si desidera utilizzare eccezioni che possono essere ingerite a monte per segnalare errori del programmatore: si desidera essere in grado di correggere l'errore .

Poiché è improbabile che un fuori limite l'accesso a un vettore faccia parte del normale flusso del programma (nel caso lo sia, hai ragione: controlla prima con size invece di far scoppiare l'eccezione), I d'accordo con la tua diagnosi: at è sostanzialmente inutile.

Answer 3

Quali sono i vantaggi dell'utilizzo di vector :: at vector :: operator []? Quando dovrei usare vector :: at piuttosto che vector :: size + vector :: operator []?

Il punto importante è che le eccezioni consentono separazione del normale flusso di codice dalla logica gestione degli errori, e un singolo blocco catch in grado di gestire i problemi derivanti da uno qualsiasi dei siti throw miriade, anche se dispersa in profondità all'interno chiamate di funzione . Quindi, non è che at() sia necessariamente più semplice per un singolo uso, ma che a volte diventi più semplice - e meno offuscante della logica del caso normale - quando hai un sacco di indicizzazione da convalidare.

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

Come esempio del mondo reale, ho un codice che converte il C++ in elementi lessicali, quindi un altro codice che sposta un indice sul vettore di token. A seconda di ciò che è incontrato, mi può 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 da controllare se hai impropriamente raggiunto la fine dell'input perché questo dipende molto dai token esatti incontrati. Il controllo esplicito in ogni punto di utilizzo è doloroso e c'è molto più spazio per errori del programmatore come incrementi pre/post, offset nel punto di utilizzo, ragionamento imperfetto sulla validità di alcuni test precedenti ecc. Kicking.

Answer 4

L'intero punto di 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 gli indici per fare riferimento a qualche tipo di risorsa che internamente memorizzi in un 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 uscire da tutti i livelli di ricorsione e solo rifiutare l'intero file (o qualsiasi tipo di struttura "grossolana"). Questo è dove è utile. Puoi semplicemente scrivere il codice di analisi come se il file fosse valido. Il codice della libreria si prenderà cura del rilevamento degli errori e puoi semplicemente rilevare l'errore a livello di massima.

Inoltre, altri contenitori, come std::map, hanno anche std::map::at che contiene semantica leggermente diverse rispetto std::map::operator[]: a può essere utilizzato su una mappa const, mentre operator[] non può. Ora, se si desidera scrivere codice agnostico del contenitore, come qualcosa che potrebbe riguardare sia const std::vector<T>& o const std::map<std::size_t, T>&, ContainerType::at sarebbe la vostra arma preferita.

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

Answer 5

Innanzitutto, se at() o operator[] non è specificato. Quando non ci sono errori, mi aspetto che abbiano circa la stessa velocità, a almeno nei build di debug. La differenza è che at() specifica esattamente ciò che accadrà in presenza di un errore limiti (un'eccezione), dove, come nel caso di operator[], è un comportamento indefinito — un incidente in tutti i sistemi che uso (g ++ e VC++), almeno quando vengono utilizzati i flag di debugging standard .(Un'altra differenza è che una volta che sono sicuro del mio codice , posso ottenere un sostanziale aumento di velocità per operator[] disattivando il debug. Se le prestazioni lo richiedono, lo — I non lo farebbe se non fosse necessario.)

In pratica, at() è raramente appropriato. Se il contesto è tale che sai che l'indice potrebbe essere non 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 abortire (e se non si sa se sia non valido o meno, suggerirei di specificare l'interfaccia della propria funzione in modo più preciso). Ci sono alcune eccezioni, tuttavia, dove l'indice non valido può risultare dall'analisi dei dati utente e l'errore dovrebbe causare l'interruzione dell'intera richiesta (ma non portare il server in basso); in questi casi, è necessaria un'eccezione e at() eseguirà per te .

Answer 6

Secondo l'articolo this, prestazioni a parte, non fa alcuna differenza usare at o operator[], solo se l'accesso è garantito all'interno della dimensione del vettore. Altrimenti, se l'accesso è basato solo sulla capacità del vettore, è più sicuro usare at.

Answer 7

at può essere più chiaro se si dispone di 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 più chiaro.

Answer 8

Qui ci sono molte risposte sbagliate. C'è davvero una sola differenza: at non controlla i limiti mentre operator[] no. Questo si applica alle build di debug e alle build di rilascio e questo è molto ben specificato dagli standard. È così semplice.

Questo rende at un metodo più lento ma è anche un consiglio davvero pessimo per non utilizzare at. Devi guardare numeri assoluti, non numeri relativi tra due. Il più delle volte, ci sono operazioni molto più costose di at. Personalmente, io uso sempre at perché non voglio un bug sgradevole per creare comportamenti indefiniti e intrufolarsi alla produzione. Io uso solo operator[] se ho la prova che è una causa significativa di qualche problema di prestazioni che mi dà fastidio.