2013-04-22 5 views
9

Perché spostare il costruttore per std::vector con l'allocatore personalizzato non deduce uno noexcept() comportamento di allocatore?perché il cursore di movimento del vettore non deduce una noexcept()?

Ciò conduce alla classe che incapsula tale vettore non può formare il vettore (altro) che può essere normalmente spostato in alcuni <algorithm> s. Anche se il tipo sottostante soddisfa i requisiti necessari (MoveInsertable e DefaultInsertable).

+0

perché potrebbero esserci persone che potrebbero buttare da una mossa costruttore –

+4

Potresti fornire del codice? Non capisco cosa intendi. La "noxcept" su cosa dei "comportamenti degli allocatori"? –

+0

Dire, "comportamenti di allocatore" indica alcune espressioni booleane su 'noexcept (allocator :: construct (...))' e 'noexcept (allocator :: destroy (...))'. – Orient

risposta

4

presumo che per "spostare costruttore per std::vector con allocatore personalizzato" si intende il allocatore-extended mossa costruttore cioè questo costruttore:

vector(vector&& v, const allocator_type& a); 

Il motivo principale è che se v.get_allocator() != a poi il costruttore deve allocare più memoria, che potrebbe lanciare bad_alloc. Non è possibile sapere in fase di compilazione se due allocatori di un determinato tipo saranno sempre uguali o meno (l'ho segnalato come un difetto, vedere LWG 2108).

N.B. lo standard non richiede questo costruttore o il costruttore di spostamento vector(vector&&)noexcept.

+0

In questo caso, "lo standard non richiede" potrebbe essere riformulato come "lo standard non consente", corretto? – mcmcc

+0

@mcmcc, no, non è corretto. Le implementazioni possono aggiungere o stringere le specifiche delle eccezioni, quindi è conforme aggiungere 'noexcept (true) 'per le specializzazioni con un tipo di allocatore che è noto per confrontare sempre uguale (ad esempio' std :: allocator') –

Problemi correlati