ciao.
E' piu performante se conosco il numero di elementi da inserire in un vector fare un resize del vector prima di inserire gli elementi?
E , sono semplici pippe o alla fine danno un risultato?
magari avendo moltissimi elementi?
ciao.
E' piu performante se conosco il numero di elementi da inserire in un vector fare un resize del vector prima di inserire gli elementi?
E , sono semplici pippe o alla fine danno un risultato?
magari avendo moltissimi elementi?
Si.E' piu performante se conosco il numero di elementi da inserire in un vector fare un resize del vector prima di inserire gli elementi?
This code and information is provided "as is" without warranty of any kind, either expressed
or implied, including but not limited to the implied warranties of merchantability and/or
fitness for a particular purpose.
<sapevatelo>
Fatto interessante: quanto a performance, tra resize e reserve ci possono essere differenze a seconda dei tipi contenuti.
Entrambe allocano tutta la memoria necessaria; tuttavia:
- la resize inizializza tutti gli elementi al valore specificato, e, oltre alla "capacity", viene alterata anche la "size" del vettore. Per assegnare i valori effettivi al vettore poi è opportuno usare l'operatore [];
- la reserve alloca la memoria necessaria e cambia la "capacity" del vettore, ma non inizializza nulla (la inizializzazione è ritardata a successive push_back, che usano il placement new per inizializzare i singoli elementi); non è possibile usare il [] per lavorare sullo spazio riservato ma non ancora considerato parte effettiva del vettore.
Da qualche benchmark che ho fatto in passato, risulta che per i tipi primitivi e probabilmente in generale per i POD l'approccio che conviene è resize+operator[]; infatti il costo dei costruttori qui è talmente basso che viene a costare di più il continuo incremento della size del vettore e le altre operazioni di bookkeeping del vector rispetto a inizializzare in massa la memoria all'inizio e copiare poi dei semplici scalari (tutte operazioni che si riducono a copie e fill bitwise).
Nel caso di classi con inizializzazioni complesse, invece, conviene quasi sempre il secondo approccio: il costruttore viene richiamato una sola volta (più costruttore di copia con placement-new), e il costo delle push_back viene ampiamente ripagato dalla mancata costruzione di default all'inizio.
Nel dubbio, comunque, reserve+push_back è la soluzione generica più sicura (visto anche che il guadagno in prestazioni per i POD con l'altro metodo non è così notevole).
</sapevatelo>
Amaro C++, il gusto pieno dell'undefined behavior.
Se poi si vuole innestare il turbo si cambia allocatore (anche se si nota più con le std::list).
This code and information is provided "as is" without warranty of any kind, either expressed
or implied, including but not limited to the implied warranties of merchantability and/or
fitness for a particular purpose.