Can placement-new and vector::data() be used to replace elements in a vector?

Question

There are two existing questions about replacing vector elements that are not assignable:

• C++ Use Unassignable Objects in Vector
• How to push_back without operator=() for const members?

A typical reason for an object to be non-assignable is that its class definition includes const members and therefore has its operator= deleted.

std::vector requires that its element type be assignable. And indeed, at least using GCC, neither direct assignment ( vec[i] = x; ), nor a combination of erase() and insert() to replace an element works when the object is not assignable.

Can a function like the following, which uses vector::data() , direct element destruction, and placement new with the copy constructor, be used to replace the element without causing undefined behaviour?

template <typename T>
inline void replace(std::vector<T> &vec, const size_t pos, const T& src)
{
  T *p = vec.data() + pos;
  p->~T();
  new (p) T(src);
}

An example of the function in use is found below. This compiles in GCC 4.7 and appears to work.

struct A
{
  const int _i;
  A(const int &i):_i(i) {}
};

int main() {
  std::vector<A> vec;
  A c1(1);
  A c2(2);

  vec.push_back(c1);
  std::cout << vec[0]._i << std::endl;

  /* To replace the element in the vector
     we cannot use this: */
  //vec[0] = c2;

  /* Nor this: */
  //vec.erase(begin(vec));
  //vec.insert(begin(vec),c2);

  /* But this we can: */
  replace(vec,0,c2);
  std::cout << vec[0]._i << std::endl;

  return 0;
}

Answer 1

This is illegal, because 3.8p7, which describes using a destructor call and placement new to recreate an object in place, specifies restrictions on the types of data members:

3.8 Object lifetime [basic.life]

7 - If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object [...] can be used to manipulate the new object, if: [...]
— the type of the original object [...] does not contain any non-static data member whose type is const-qualified or a reference type [...]

So since your object contains a const data member, after the destructor call and placement new the vector's internal data pointer becomes invalid when used to refer to the first element; I think any sensible reading would conclude that the same applies to other elements as well.

The justification for this is that the optimiser is entitled to assume that const and reference data members are not respectively modified or reseated:

struct A { const int i; int &j; };
int foo() {
    int x = 5;
    std::vector<A> v{{4, x}};
    bar(v);                      // opaque
    return v[0].i + v[0].j;      // optimised to `return 9;`
}

Answer 2

@ecatmur's answer is correct as of its time of writing. In C++17, we now get std::launder ( wg21 proposal P0137 ). This was added to make things such as std::optional work with const members amongst other cases. As long as you remember to launder (ie clean up) your memory accesses, then this will now work without invoking undefined behaviour.

Answer 3

As of c++20 this is legal since the member is const but not the complete object. C++ 20 also offers some new functions simplifying destruction and construction: std::destroy_at and std::construct_at

If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if the original object is transparently replaceable (see below) by the new object. An object o1 is transparently replaceable by an object o2 if:

• (8.1) the storage that o2 occupies exactly overlays the storage that o1 occupied, and
• (8.2) o1 and o2 are of the same type (ignoring the top-level cv-qualifiers), and
• (8.3) o1 is not a complete const object, and
• (8.4) neither o1 nor o2 is a potentially-overlapping subobject ([intro.object]), and
• (8.5) either o1 and o2 are both complete objects, or o1 and o2 are direct subobjects of objects p1 and p2, respectively, and p1 is transparently replaceable by p2.

So, replace the lines that call replace(...) with this:

 std::construct_at(&vec[0]._i, c._i); 

You would need to precede this with destroy_at if, for instance, the const was a std::string .