È sicuro respingere un elemento dallo stesso vettore?

vector<int> v;
v.push_back(1);
v.push_back(v[0]);

Se il secondo push_back provoca una riallocazione, il riferimento al primo numero intero nel vettore non sarà più valido. Quindi questo non è sicuro?

vector<int> v;
v.push_back(1);
v.reserve(v.size() + 1);
v.push_back(v[0]);

Questo lo rende sicuro?

Sembra che http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526 abbia affrontato questo problema (o qualcosa di molto simile ad esso) come un potenziale difetto dello standard:

1) I parametri presi dal riferimento const possono essere modificati durante l'esecuzione della funzione

Esempi:

Dato std :: vector v:

v.insert (v.begin (), v [2]);

v [2] può essere modificato spostando elementi del vettore

La risoluzione proposta era che questo non era un difetto:

vector :: insert (iter, value) è necessario per funzionare perché lo standard non autorizza il suo funzionamento.

Sì, è sicuro e le implementazioni di librerie standard saltano attraverso i cerchi per renderlo tale.

Credo che gli implementatori riportino questo requisito al 23.2 / 11 in qualche modo, ma non riesco a capire come, e non riesco a trovare qualcosa di più concreto. Il meglio che posso trovare è questo articolo:

http://www.drdobbs.com/cpp/copying-container-elements-from-the-c-li/240155771

Il controllo delle implementazioni di libc ++ e libstdc ++ mostra che sono anche sicuri.

Lo standard garantisce che anche il tuo primo esempio sia sicuro. Citando C ++ 11

[sequence.reqmts]

3 Nelle tabelle 100 e 101 ... Xindica una classe contenitore sequenza, aindica un valore Xcontenente elementi di tipo T, ... tindica un valore o un valore costante diX::value_type

16 Tabella 101 ...

Espressione a.push_back(t) Tipo di ritorno void Semantica operativa Aggiunge una copia di t. Richiede: T deve essere CopyInsertablein X. Contenitore basic_string , deque, list,vector

Quindi, anche se non è esattamente banale, l'implementazione deve garantire che non invaliderà il riferimento durante l'esecuzione di push_back.

Non è ovvio che il primo esempio sia sicuro, poiché l'implementazione più semplice di push_backsarebbe innanzitutto riallocare il vettore, se necessario, e quindi copiare il riferimento.

Ma almeno sembra essere sicuro con Visual Studio 2010. La sua implementazione push_backfa una gestione speciale del caso quando si respinge un elemento nel vettore. Il codice è strutturato come segue:

void push_back(const _Ty& _Val)
    {   // insert element at end
    if (_Inside(_STD addressof(_Val)))
        {   // push back an element
                    ...
        }
    else
        {   // push back a non-element
                    ...
        }
    }

Questa non è una garanzia dallo standard, ma come un altro punto dati, v.push_back(v[0])è sicura per libc ++ di LLVM .

Lestd::vector::push_back chiamate di libc ++__push_back_slow_path quando è necessario riallocare la memoria:

void __push_back_slow_path(_Up& __x) {
  allocator_type& __a = this->__alloc();
  __split_buffer<value_type, allocator_type&> __v(__recommend(size() + 1), 
                                                  size(), 
                                                  __a);
  // Note that we construct a copy of __x before deallocating
  // the existing storage or moving existing elements.
  __alloc_traits::construct(__a, 
                            _VSTD::__to_raw_pointer(__v.__end_), 
                            _VSTD::forward<_Up>(__x));
  __v.__end_++;
  // Moving existing elements happens here:
  __swap_out_circular_buffer(__v);
  // When __v goes out of scope, __x will be invalid.
}

La prima versione NON è assolutamente sicura:

Le operazioni su iteratori ottenute chiamando un contenitore di libreria standard o una funzione membro stringa possono accedere al contenitore sottostante, ma non devono modificarlo. [Nota: in particolare, le operazioni del contenitore che invalidano gli iteratori sono in conflitto con le operazioni sugli iteratori associati a quel contenitore. - nota finale]

dalla sezione 17.6.5.9

Si noti che questa è la sezione sulle corse di dati, a cui la gente normalmente pensa in congiunzione con il threading ... ma la definizione effettiva implica relazioni "prima" e non vedo alcuna relazione di ordinamento tra i molteplici effetti collaterali di push_backin gioca qui, vale a dire che l'invalidazione di riferimento sembra non essere definita come ordinata rispetto alla copia-costruzione del nuovo elemento di coda.

È completamente sicuro.

Nel tuo secondo esempio hai

v.reserve(v.size() + 1);

che non è necessario perché se il vettore esce dalle sue dimensioni, implica il reserve.

Vector è responsabile di questa roba, non tu.

Entrambi sono sicuri poiché push_back copierà il valore, non il riferimento. Se stai memorizzando puntatori, questo è ancora sicuro per quanto riguarda il vettore, ma sappi solo che avrai due elementi del tuo vettore che puntano agli stessi dati.

Sezione 23.2.1 Requisiti generali del contenitore

16

• a.push_back (t) Aggiunge una copia di t. Richiede: T deve essere CopyInsertable in X.
• a.push_back (rv) Aggiunge una copia di rv. Richiede: T deve essere MoveInsertable in X.

Le implementazioni di push_back devono pertanto garantire l'inserimento di una copia di v[0] . Per contro esempio, supponendo un'implementazione che si riallocerebbe prima della copia, non aggiungerebbe sicuramente una copia v[0]e in quanto tale violerebbe le specifiche.

Dal 23.3.6.5/1: Causes reallocation if the new size is greater than the old capacity. If no reallocation happens, all the iterators and references before the insertion point remain valid.

Poiché stiamo inserendo alla fine, nessun riferimento verrà invalidato se il vettore non viene ridimensionato. Quindi, se il vettore è capacity() > size()quindi garantito, altrimenti è garantito un comportamento indefinito.