Il ridimensionamento in C ++ è scomodo a causa della potenziale necessità di chiamare costruttori e distruttori.
Non penso che ci sia una ragione fondamentale per cui in C ++ non potresti avere un resize[]
operatore con cui andare new[]
e delete[]
, che ha fatto qualcosa di simile a questo:
newbuf = new Type[newsize];
std::copy_n(oldbuf, std::min(oldsize, newsize), newbuf);
delete[] oldbuf;
return newbuf;
Ovviamente oldsize
verrebbe recuperato da una posizione segreta, lo stesso in cui si trova delete[]
, e Type
verrebbe dal tipo di operando. resize[]
fallirebbe dove il tipo non è copiabili, il che è corretto, poiché tali oggetti semplicemente non possono essere riposizionati. Infine, il codice precedente costruisce in modo predefinito gli oggetti prima di assegnarli, cosa che non vorresti come comportamento effettivo.
Esiste una possibile ottimizzazione in cui newsize <= oldsize
chiamare i distruttori per gli oggetti "oltre la fine" dell'array appena ridotto e non fare nient'altro. Lo standard dovrebbe definire se questa ottimizzazione è richiesta (come quando si tratta di resize()
un vettore), consentita ma non specificata, consentita ma dipendente dall'implementazione o vietata.
La domanda che dovresti quindi porti è: "è effettivamente utile fornire questo, dato che vector
lo fa anche, ed è progettato specificamente per fornire un contenitore ridimensionabile (di memoria contigua - quel requisito è stato omesso in C ++ 98 ma risolto in C ++ 03) che si adatta meglio agli array con i modi di fare le cose C ++? "
Penso che la risposta sia ampiamente ritenuta "no". Se vuoi creare buffer ridimensionabili in C, usa malloc / free / realloc
, che sono disponibili in C ++. Se vuoi creare buffer ridimensionabili in modo C ++, usa un vettore (o deque
, se non hai effettivamente bisogno di archiviazione contigua). Non provare a mescolare i due utilizzando new[]
per i buffer non elaborati, a meno che non stai implementando un contenitore simile a un vettore.