È consentito std :: vector :: push_back di lanciare per qualsiasi ragione diversa dalla riallocazione o costruzione fallita?

Question

Considerare:

std::vector<int> v; 
v.reserve(1); 
v.push_back(1); // is this statement guaranteed not to throw? 

ho scelto int perché non ha costruttori che potrebbero gettare - ovviamente se qualche copia costruttore della T getta, quindi tale eccezione sfugge vector<T>::push_back.

Questa domanda vale tanto per insert come push_back, ma è stato ispirato da Is it safe to push_back 'dynamically allocated object' to vector?, che avviene per chiedere di push_back.

Nello standard C++ 03 e C++ 0x/FCD, le descrizioni di vector::insert affermano che se non avviene alcuna riallocazione, gli iteratori/riferimenti prima del punto di inserimento rimangono validi. Loro non dicono affermano che se non avviene alcuna riallocazione, non viene lanciata alcuna eccezione (a meno che dai costruttori ecc. Di T).

C'è qualcosa altrove nello standard per garantire questo?

Non mi aspetto che push_back esegua tutto ciò che potrebbe generare in questo caso. L'implementazione GNU no. La domanda è se lo standard lo proibisca.

Come follow-up, qualcuno può pensare a un motivo per cui qualsiasi implementazione dovrebbe essere lanciata? Il meglio che posso pensare, è che se una chiamata a reserve aumenta la capacità ad un valore superiore a max_size(), allora insert è forse possibile lanciare length_error quando la dimensione massima viene superata. Sarebbe inutile aumentare la capacità oltre lo max_size(), ma non vedo immediatamente nulla che lo impedisca, o [Modifica: il tuo allocatore probabilmente ti impedirebbe di aumentare la capacità oltre max_size, quindi questo suggerimento potrebbe non essere valido.]

Answer 1

Bene , dipende dall'allocatore che stai usando.

A parte l'allocatore, l'unica cosa che si può fare affidamento su è che push_back() e push_front() sono garantiti per essere noop se viene generata un'eccezione (23,1-10). Lo standard sicuramente non vieta al push_back() di lanciare eccezioni.