Безопасно ли возвращать элемент из того же вектора?

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

Если второй push_back вызывает перераспределение, ссылка на первое целое число в векторе больше не будет действительной. Так это небезопасно?

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

Это делает его безопасным?

Похоже, http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526 решает эту проблему (или что-то очень похожее на нее) как потенциальный дефект в стандарте:

1) Параметры, взятые по константной ссылке, могут быть изменены во время выполнения функции

Примеры:

Учитывая std :: vector v:

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

v [2] можно изменить, перемещая элементы вектора

Предлагаемое решение заключалось в том, что это не было дефектом:

vector :: insert (iter, value) требуется для работы, потому что стандарт не дает разрешения, чтобы он не работал.

Да, это безопасно, и реализации стандартных библиотек прыгают через препятствия, чтобы сделать это так.

Я считаю, что разработчики каким-то образом прослеживают это требование до 23.2 / 11, но я не могу понять, как это сделать, и не могу найти чего-то более конкретного. Лучшее, что я могу найти, - это эта статья:

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

Проверка реализаций libc ++ и libstdc ++ показывает, что они также безопасны.

Стандарт гарантирует безопасность даже первого примера. Цитирование C ++ 11

[sequence.reqmts]

3 В таблицах 100 и 101 ... Xобозначает класс контейнера последовательности, aобозначает значение, Xсодержащее элементы типа T, ... tобозначает lvalue или const rvalue дляX::value_type

16 Таблица 101 ...

Выражение a.push_back(t) Тип возвращаемого значения void Операционная семантика Добавляет копию Requires t. : T должно быть CopyInsertableв X. Контейнер basic_string , deque, list,vector

Таким образом, даже если это не совсем тривиально, реализация должна гарантировать, что она не сделает ссылку недействительной при выполнении push_back.

Не очевидно, что первый пример безопасен, потому что простейшей реализацией push_backбыло бы сначала перераспределить вектор, если необходимо, а затем скопировать ссылку.

Но, по крайней мере, это кажется безопасным с Visual Studio 2010. Его реализация push_backвыполняет особую обработку случая, когда вы возвращаете элемент в векторе. Код имеет следующую структуру:

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

Это не гарантия стандарта, но, как еще одна точка данных, v.push_back(v[0])безопасна для библиотеки LLVM libc ++ .

Libc ++ Sstd::vector::push_back вызовы , __push_back_slow_pathкогда ему необходимо перераспределить память:

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

Первая версия определенно НЕ безопасна:

Операции с итераторами, полученные путем вызова контейнера стандартной библиотеки или строковой функции-члена, могут обращаться к базовому контейнеру, но не должны его изменять. [Примечание: В частности, операции контейнера, которые делают итераторы недействительными, конфликтуют с операциями над итераторами, связанными с этим контейнером. - конец примечания]

из раздела 17.6.5.9

Обратите внимание, что это раздел о гонках данных, который люди обычно думают в связи с потоковой передачей ... но фактическое определение включает отношения «происходит раньше», и я не вижу какой-либо упорядочивающей взаимосвязи между несколькими побочными эффектами push_backin play здесь, а именно, признание недействительности ссылки, похоже, не определяется как упорядоченное в отношении создания копии нового хвостового элемента.

Это совершенно безопасно.

Во втором примере у вас есть

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

который не нужен, потому что, если вектор выходит за пределы своего размера, он будет подразумевать reserve.

За это отвечает Vector, а не вы.

Оба безопасны, поскольку push_back скопирует значение, а не ссылку. Если вы храните указатели, это все еще безопасно для вектора, но просто знайте, что у вас будут два элемента вашего вектора, указывающие на одни и те же данные.

Раздел 23.2.1 Общие требования к контейнерам

16

• a.push_back (t) Добавляет копию t. Требуется: T должен быть CopyInsertable в X.
• a.push_back (rv) Добавляет копию rv. Требуется: T должен быть MoveInsertable в X.

Поэтому реализации push_back должны гарантировать, что вставлена копия v[0] . В противоположном примере, если предположить, что реализация будет перераспределяться перед копированием, она не обязательно добавит копию v[0]и, как таковая, нарушит спецификации.

Начиная с 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.

Поскольку мы вставляем в конце, никакие ссылки не будут признаны недействительными, если размер вектора не будет изменен. Итак, если вектор, capacity() > size()то он гарантированно работает, в противном случае гарантированно будет неопределенное поведение.