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

Midweek

even if it was valid, what would it solve? vector still calls the assignment operator and not your replace function. – Primulaceous

@jalf the point is you never invoke the assignment operator at all. – Warthman

Almost every STL implementation (and now standard library) i've ever seen utilizes this very technique to the high-heavens for sequence management. The only part of this specific usage you have here that raises my brow is the potential that the placement-construction may throw, at which time you now have a destroyed element in the vector, but the vector doesn't know that and will try to destroy it again on its own destruction. Nice question, btw. – Warthman

Having const members is rarely a good idea in C++. Why does your class have const members? – Russellrusset

This can not been compiled GCC 4.2.4.Because, when you call push_back,vector require the type copyassignable. – Everywhere

@WhozCraig: I agree, maybe conditioning this function on the copy constructor being nothrow ? (is_nothrow_copy_constructible) – Diopside

@bbg: That requirement was removed in C++11. – Senaidasenalda

@bbg: There is no reason to though, push_back is about making a copy into an new slot, not overriding an old one. – Diopside

@FredOverflow I don't actually have this problem right now. The question is entirely inspired by the other two questions. But then... why couldn't you reasonably have data members that you think should never change after construction. Maybe a somewhat rare requirement, but not unreasonable I think. – Midweek

Because value semantics get in the way. Coming from Java or other "reference-oriented" programming languages, people expect to be able to bind constant objects to mutable variables. As soon as you have one const member in class X, you cannot assign to variables of type X anymore (because variables are nothing more than named objects in C++), and that's rarely what people want. – Russellrusset

This doesn't solve the problem in any way, as the requirement stands: any object in a vector must be copyable. And it's definitely an antipattern, in that it isn't exception safe, and will raise havoc in the case of inheritance. If you want to support assignment, support assignment. – Bailiwick

@FredOverflow I can see your point, and indeed the desire to do vec[i] = x to replace the object at the ith slot with x (rather than to copy the contents of x over the contents of the object at the ith slot) is perhaps rooted in the idea to view vec[i] as the ith slot (and not the object stored at the ith slot). So it's a reference-way of looking at things, not a value-way. – Midweek

@JamesKanze Yes, the requirement for the vector elements to be assignable still stands, and it that sense the proposed method may invoke UB because it uses a vector in a way it's not supposed to. But that's a purely formal reason. Exception safety is a more practical concern, as discussed by others above, and indeed inheritance is something I haven't thought about. Good point. – Midweek

@Midweek Compilers can and do enforce this requirement. Try compiling with g++ -D_GLIBCXX_CONCEPT_CHECKS. (At one point, it was the intent to require this to fail to compiler. This was deferred since concepts didn't make it into this release, but I would expect it to be the case in the next version of the standard.) – Bailiwick

@JamesKanze Cool.. I didn't know about that flag. (And yes, with concepts in place, I'd also expect this to fail.) – Midweek

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;`
}

Servile

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 (i.e. clean up) your memory accesses, then this will now work without invoking undefined behaviour.

Bootless

On SO, see What is the purpose of std::launder? and others. – Dysart

C++17 also has the uninitialized memory algorithms that can be used to hide the nastiness of the explicit dtor and placement new. – Mature

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.

Lymphatic