18

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

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;
}
Community
  • 1
  • 1
jogojapan
  • 68,383
  • 11
  • 101
  • 131
  • even if it was valid, what would it solve? `vector` still calls the assignment operator and not your replace function. – jalf Oct 16 '12 at 06:04
  • 2
    @jalf the point is you never invoke the assignment operator at all. – WhozCraig Oct 16 '12 at 06:07
  • 4
    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. – WhozCraig Oct 16 '12 at 06:08
  • 1
    Having `const` members is rarely a good idea in C++. Why does your class have `const` members? – fredoverflow Oct 16 '12 at 06:30
  • This can not been compiled GCC 4.2.4.Because, when you call push_back,vector require the type copyassignable. – bbg Oct 16 '12 at 06:39
  • 2
    @WhozCraig: I agree, maybe conditioning this function on the copy constructor being nothrow ? ([`is_nothrow_copy_constructible`](http://en.cppreference.com/w/cpp/types/is_copy_constructible)) – Matthieu M. Oct 16 '12 at 06:41
  • 1
    @bbg: That requirement was removed in C++11. – Jesse Good Oct 16 '12 at 06:41
  • @bbg: There is no reason to though, `push_back` is about making a copy into an new slot, not overriding an old one. – Matthieu M. Oct 16 '12 at 06:42
  • @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. – jogojapan Oct 16 '12 at 06:45
  • 2
    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. – fredoverflow Oct 16 '12 at 06:51
  • 2
    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. – James Kanze Oct 16 '12 at 07:16
  • @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. – jogojapan Oct 16 '12 at 07:18
  • @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. – jogojapan Oct 16 '12 at 07:29
  • 3
    @jogojapan 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.) – James Kanze Oct 16 '12 at 07:48
  • @JamesKanze Cool.. I didn't know about that flag. (And yes, with concepts in place, I'd also expect this to fail.) – jogojapan Oct 16 '12 at 07:53

3 Answers3

16

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;`
}
ecatmur
  • 152,476
  • 27
  • 293
  • 366
4

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

Rich L
  • 1,905
  • 2
  • 19
  • 30
  • On SO, see [What is the purpose of std::launder?](https://stackoverflow.com/questions/39382501/what-is-the-purpose-of-stdlaunder) and others. – underscore_d Oct 30 '17 at 13:19
  • C++17 also has the [uninitialized memory algorithms](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0040r3.html) that can be used to hide the nastiness of the explicit dtor and placement new. – Oktalist Oct 30 '17 at 15:31
1

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.

jogojapan
  • 68,383
  • 11
  • 101
  • 131
doug
  • 3,840
  • 1
  • 14
  • 18