¿Es seguro hacer retroceder un elemento del mismo vector?

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

Si el segundo push_back provoca una reasignación, la referencia al primer entero en el vector ya no será válida. ¿Entonces esto no es seguro?

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

Esto lo hace seguro?

Parece que http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526 abordó este problema (o algo muy similar) como un defecto potencial en el estándar:

1) Los parámetros tomados por referencia constante se pueden cambiar durante la ejecución de la función

Ejemplos:

Dado std :: vector v:

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

v [2] se puede cambiar moviendo elementos del vector

La resolución propuesta fue que esto no era un defecto:

Se requiere vector :: insert (iter, value) para funcionar porque el estándar no da permiso para que no funcione.

Sí, es seguro, y las implementaciones de bibliotecas estándar saltan los aros para que así sea.

Creo que los implementadores rastrean este requisito hasta 23.2 / 11 de alguna manera, pero no puedo entender cómo, y tampoco puedo encontrar algo más concreto. Lo mejor que puedo encontrar es este artículo:

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

La inspección de las implementaciones de libc ++ y libstdc ++ muestra que también son seguras.

El estándar garantiza que incluso su primer ejemplo sea seguro. Citando C ++ 11

[secuencia.reqmts]

3 En las Tablas 100 y 101 ... Xdenota una clase de contenedor de secuencia, adenota un valor de Xelementos de tipo que contiene T, ... tdenota un valor l o un valor constante deX::value_type

16 Tabla 101 ...

a.push_back(t) Tipo de retorno de expresión void Semántica operacional Agrega una copia de t. Requiere: T debe estar CopyInsertableen X. Envase basic_string , deque, list,vector

Entonces, aunque no es exactamente trivial, la implementación debe garantizar que no invalidará la referencia al hacer el push_back .

No es obvio que el primer ejemplo es seguro, porque la implementación más simple de push_back sería reasignar primero el vector, si es necesario, y luego copiar la referencia.

Pero al menos parece seguro con Visual Studio 2010. Su implementación push_backhace un manejo especial del caso cuando empujas un elemento en el vector. El código está estructurado de la siguiente manera:

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
                    ...
        }
    }

Esto no es una garantía del estándar, pero como otro punto de datos, v.push_back(v[0])es seguro para libc ++ de LLVM .

std::vector::push_backLlamadas de libc ++__push_back_slow_path cuando necesita reasignar 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 primera versión definitivamente NO es segura:

Las operaciones en iteradores obtenidas llamando a un contenedor de biblioteca estándar o una función de miembro de cadena pueden acceder al contenedor subyacente, pero no lo modificarán. [Nota: en particular, las operaciones de contenedor que invalidan los iteradores entran en conflicto con las operaciones en los iteradores asociados con ese contenedor. - nota final]

de la sección 17.6.5.9

Tenga en cuenta que esta es la sección sobre carreras de datos, en la que las personas normalmente piensan junto con el enhebrado ... pero la definición real implica relaciones "pasa antes", y no veo ninguna relación de orden entre los múltiples efectos secundarios de push_backin jugar aquí, es decir, la invalidación de referencia parece no definirse como ordenada con respecto a la construcción de copia del nuevo elemento de cola.

Es completamente seguro

En tu segundo ejemplo tienes

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

lo cual no es necesario porque si el vector sale de su tamaño, implicará el reserve.

Vector es responsable de estas cosas, no tú.

Ambos son seguros ya que push_back copiará el valor, no la referencia. Si está almacenando punteros, eso todavía es seguro en lo que respecta al vector, pero solo sepa que tendrá dos elementos de su vector apuntando a los mismos datos.

Sección 23.2.1 Requisitos generales del contenedor

dieciséis

• a.push_back (t) Agrega una copia de t. Requiere: T será CopyInsertable en X.
• a.push_back (rv) Agrega una copia de rv. Requiere: T será MoveInsertable en X.

Por lo tanto, las implementaciones de push_back deben garantizar que se inserte una copia de v[0] . Por contraejemplo, suponiendo una implementación que se reasignaría antes de copiar, seguramente no agregaría una copia v[0]y, como tal, violaría las especificaciones.

Desde 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.

Como estamos insertando al final, no se invalidarán las referencias si el vector no cambia de tamaño. Entonces, si el vector está capacity() > size()garantizado para funcionar, de lo contrario se garantiza que será un comportamiento indefinido.