Why is that undefined behaviour?
struct s
{
const int id; // <-- const member
s(int id):
id(id)
{}
s& operator =(const s& m) {
return *new(this) s(m); // <-- undefined behavior?
}
};
(Quote from the standard would be nice).
This question arose from this answer.
There is nothing that makes the shown code snippet inherently UB. However, it is almost certain UB will follow immediately under any normal usage.
From [basic.life]/8 (emphasis mine)
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 storage for the new object exactly overlays the storage location which the original object occupied, and
the new object is of the same type as the original object (ignoring the top-level cv-qualifiers), and
the type of the original object is not const-qualified, and, if a class type, does not contain any non-static data member whose type is const-qualified or a reference type, and
the original object was a most derived object of type T and the new object is a most derived object of type T (that is, they are not base class subobjects).
Since there is a const member in s, using the original variable after a call to operator= will be UB.
s var{42};
var = s{420}; // OK
do_something(var.id); // UB! Reuses s through original name
do_something(std::launder(&var)->id); // OK, this is what launder is used for
Related
This is a follow-up to my previous question where I seem to have made the problem more involved than I had originally intended. (See discussions in question and answer comments there.)
This question is a slight modification of the original question removing the issue of special rules during construction/destruction of the enclosing object.
Is it allowed to reuse storage of a non-static data member during the lifetime of its enclosing object and if so under what conditions?
Consider the program
#include<new>
#include<type_traits>
using T = /*some type*/;
using U = /*some type*/;
static_assert(std::is_object_v<T>);
static_assert(std::is_object_v<U>);
static_assert(sizeof(U) <= sizeof(T));
static_assert(alignof(U) <= alignof(T));
struct A {
T t /*initializer*/;
U* u;
void construct() {
t.~T();
u = ::new(static_cast<void*>(&t)) U /*initializer*/;
}
void destruct() {
u->~U();
::new(static_cast<void*>(&t)) T /*initializer*/;
}
A() = default;
A(const A&) = delete;
A(A&&) = delete;
A& operator=(const A&) = delete;
A& operator=(A&&) = delete;
};
int main() {
auto a = new A;
a->construct();
*(a->u) = /*some assignment*/;
a->destruct(); /*optional*/
delete a; /*optional*/
A b; /*alternative*/
b.construct(); /*alternative*/
*(b.u) = /*some assignment*/; /*alternative*/
b.destruct(); /*alternative*/
}
Aside from the static_asserts assume that the initializers, destructors and assignments of T and U do not throw.
What conditions do object types T and U need to satisfy additionally, so that the program has defined behavior, if any?
Does it depend on the destructor of A actually being called (e.g. on whether the /*optional*/ or /*alternative*/ lines are present)?.
Does it depend on the storage duration of A, e.g. whether /*alternative*/ lines in main are used instead?
Note that the program does not use the t member after the placement-new, except in the destructor and the destruct function. Of course using it while its storage is occupied by a different type is not allowed.
Also note that the program constructs an object of the original type in t before its destructor is called in all execution paths since I disallowed T and U to throw exceptions.
Please also note that I do not encourage anyone to write code like that. My intention is to understand details of the language better. In particular I did not find anything forbidding such placement-news as long as the destructor is not called, at least.
If a is destroyed (whether by delete or by falling out of scope), then t.~T() is called, which is UB if t isn't actually a T (by not calling destruct).
This doesn't apply if
the destructor of T is trivial, or
for delete U is derived from T, or
you're using a destroying delete
After destruct is called you are not allowed to use t if T has const or reference members (until C++20).
Apart from that there is no restriction on what you do with the class as written as far as I can see.
This answer is based on the draft available at http://eel.is/c++draft/
We can try to apply (by checking each condition) what I've decided to call the "undead object" clause to any previous object that used to exist, here we apply it to the member t of type T:
Lifetime [basic.life]/8
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:
(8.1) the storage for the new object exactly overlays the storage
location which the original object occupied, and
(8.2) the new object is of the same type as the original object
(ignoring the top-level cv-qualifiers), and
(8.3) the original object is neither a complete object that is
const-qualified nor a subobject of such an object, and
(8.4) neither the original object nor the new object is a
potentially-overlapping subobject ([intro.object]).
Conditions 1 and 2 are automatically guaranteed by the use of placement new on the old member:
struct A {
T t /*initializer*/; (...)
void destruct() { (...)
::new(static_cast<void*>(&t)) T /*initializer*/;
}
The location is the same and the type is the same. Both conditions are easily verified.
Neither A objects created:
auto a = new A;
...
A b; /*alternative*/
are const qualified complete objects so t isn't a member of a const qualified complete object. Condition 3 is met.
Now the definition of potentially-overlapping is in Object model [intro.object]/7:
A potentially-overlapping subobject is either:
(7.1) a base class subobject, or
(7.2) a non-static data member declared with the no_unique_address
attribute.
The t member is neither and condition 4 is met.
All 4 conditions are met so the member name t can be used to name the new object.
[Note that at no point I even mentioned the fact the subobject isn't a const member not its subobjects. That isn't part of the latest draft.
It means that a const sub object can legally have its value changed, and a reference member can have its referent changed for an existing object. This is more than unsettling and probably not supported by many compilers. End note.]
Beware, we're skirting the dragon's lair.
Consider the following two classes:
struct Base {
std::string const *str;
};
struct Foo : Base {
Foo() { std::cout << *str << "\n"; }
};
As you can see, I'm accessing an uninitialized pointer. Or am I?
Let's assume I'm only working with Base classes that are trivial, nothing more than (potentially nested) bags of pointers.
static_assert(std::is_trivial<Base>{}, "!");
I would like to construct Foo in three steps:
Allocate raw storage for a Foo
Initialize a suitably-placed Base subobject via placement-new
Construct Foo via placement-new.
My implementation is as follows:
std::unique_ptr<Foo> makeFooWithBase(std::string const &str) {
static_assert(std::is_trivial<Base>{}, "!");
// (1)
auto storage = std::make_unique<
std::aligned_storage_t<sizeof(Foo), alignof(Foo)>
>();
Foo * const object = reinterpret_cast<Foo *>(storage.get());
Base * const base = object;
// (2)
new (base) Base{&str};
// (3)
new (object) Foo();
storage.release();
return std::unique_ptr<Foo>{object};
}
Since Base is trivial, my understanding is that:
Skipping the trivial destructor of the Base constructed at (2) is fine;
The trivial default constructor of the Base subobject constructed as part of the Foo at (3) does nothing;
And so Foo receives an initialized pointer, and all is well.
Of course, this is what happens in practice, even at -O3 (see for yourself!).
But is it safe, or will the dragon snatch and eat me one day?
This seems to be explicitly disallowed by the standard.
Ending an objects lifetime, and starting a new objects
lifetime in the same location is explicitly allowed,
unless it's a base class:
§3.8 Object Lifetime
§3.8.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, 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 storage for the new object exactly overlays the storage location
which the original object occupied, and
the new object is of the
same type as the original object (ignoring the top-level
cv-qualifiers), and
[snip] and
the original object was a most derived object (1.8) of type T and the
new object is a most derived object of type T (that is, they are not
base class subobjects).
This question already has answers here:
Is it allowed to write an instance of Derived over an instance of Base?
(4 answers)
Closed 8 years ago.
#include <cstdlib>
struct B {
virtual void f();
void mutate();
virtual ~B();
};
struct D1 : B { void f(); };
struct D2 : B { void f(); };
void B::mutate() {
new (this) D2; // reuses storage — ends the lifetime of *this
f(); // undefined behavior - WHY????
... = this; // OK, this points to valid memory
}
I need to be explained why f() invokation has UB? new (this) D2; reuses storage, but it also call a constructor for D2 and since starts lifetime of a new object. In that case f() equals to this -> f(). That is we just call f() member function of D2. Who knows why it is UB?
The standard shows this example § 3.8 67 N3690:
struct C {
int i;
void f();
const C& operator=( const C& );
};
const C& C::operator=( const C& other) {
if ( this != &other ) {
this->~C(); // lifetime of *this ends
new (this) C(other); // new object of type C created
f(); // well-defined
}
return *this;
}
C c1;
C c2;
c1 = c2; // well-defined
c1.f(); // well-defined; c1 refers to a new object of type C
Notice that this example is terminating the lifetime of the object before constructing the new object in-place (compare to your code, which does not call the destructor).
But even if you did, the standard also says:
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 storage for the new object exactly overlays the storage location
which the original object occupied, and — the new object is of the
same type as the original object (ignoring the top-level
cv-qualifiers), and
— the type of the original object is not
const-qualified, and, if a class type, does not contain any non-static
data member whose type is const-qualified or a reference type, and
— the original object was a most derived object (1.8) of type T and the
new object is a most derived object of type T (that is, they are not
base class subobjects).
notice the 'and' words, the above conditions must all be fulfilled.
Since you're not fulfilling all the conditions (you have a derived object in-placed into the memory space of a base class object), you have undefined behavior when referencing stuff with an implicit or explicit use of this pointer.
Depending on the compiler implementation this might or might now blow because a base class virtual object reserves some space for the vtable, in-place constructing an object of a derived type which overrides some of the virtual functions means the vtable might be different, put alignment issues and other low-level internals and you'll have that a simple sizeof won't suffice to determine if your code is right or not.
This construct is very interesting:
The placement-new is not guaranteed to call the destructor of the object. So this code will not properly ensure end of life of the object.
So in principle you should call the destructor before reusing the object. But then you would continue to execute a member function of an object that is dead. According to standard section.9.3.1/2 If a non-static member function of a class X is called for an object that is not of type X, or of a type derived from X, the behavior is undefined.
If you don't explicitely delete your object, as you do in your code, you then recreate a new object (constructing a second B without destoying the first one, then D2 ot top of this new B).
When the creation of your new object is finished, the identity of your current object has in fact changed while executing the function. You cannot be sure if the pointer to the virtual function that will be called was read before your placement-new (thus the old pointer to D1::f) or after (thus D2::f).
By the way, it's exactly for this reason, that there are some constraints about what you can or can't do in a union, where a same memory place is shared for different active objects (see Point 9.5/2 and perticularly point 9.5/4 in the standard).
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;
}
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'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.
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.
Given the following code:
class foo
{
};
class bar: public foo
{
public:
~bar() { printf("~bar()\n"); }
};
class zab: public foo
{
public:
~zab() { printf("~zab()\n"); }
};
struct foo_holder
{
const foo &f;
};
int main()
{
foo_holder holder[]= { {bar()}, {zab()} };
printf("done!\n");
return 0;
}
the output is:
~bar()
~zab()
done!
C++0x has a clause that dictates this can create dangling references when used as a new initializer, but it says nothing (at least nothing I can find) about aggregate initialization of const references with temporaries.
Is this unspecified behavior then?
It isn't mentioned in the list of exceptions, therefore the lifetime to temporary should be extended to match lifetime of (array of) foo_holders. However, this looks like oversight to me, perhaps submitting Defect Report might be good idea.
§12.2/5 states, that when reference is bound to a temporary, the lifetime of temporary is extended to match lifetime of the reference and because const foo& f is member of foo_holder, the lifetime of the reference is matching lifetime of foo_holder, according to §3.7.5/1:
The storage duration of member subobjects, base class subobjects and array elements is that of their complete object (1.8).
This might be little bit tricky to interpret considering references, because §3.8/1 states, that lifetime of object ends when the storage is released or reused:
The lifetime of an object of type T ends when:
— if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or
— the storage which the object occupies is reused or released.
however, it is left unspecified whether references use storage or not; §8.3.2/4 says
It is unspecified whether or not a reference requires storage (3.7).
Perhaps someone with better knowledge of standard would know this better.
I got an answer on comp.std.c++:
http://groups.google.com/group/comp.std.c++/msg/9e779c0154d2f21b
Basically, the standard does not explicitly address it; therefore, it should behave the same as a reference declared locally.