You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Note 1: When invoked on ranges of potentially-overlapping subobjects ([intro.object]), the algorithms specified in [specialized.algorithms] result in undefined behavior. — end note]
However, this is a non-normative note, and maybe sometimes incorrect.
In this example
#include<memory>intmain()
{
structB {};
structD : B {};
D d;
std::construct_at(static_cast<B*>(&d));
// or use an uninitialized_* algorithm to create a new B object// ... other operationsstd::construct_at(&d);
}
the newly created B object doesn't transparently replace the original base class subobject, and hence the lifetime of d is ended by the operation. But the program may still have well-defined behavior, as long as the pointer or reference to d or its base class subobject is carefully used.
The text was updated successfully, but these errors were encountered:
I was trying to make a point that complete-object initialization "on top of" a subobject can zero tail padding bits where some other object lives, but this isn't an issue for the C++ abstract machine: storage reuse ends the lifetime of "other object" anyway. The note isn't clear enough to communicate anything but FUD in any case. We could change it to "can result in undefined behavior" to make it correct, but without any clarification I think it would still be useless. ("[Note: Here there be dragons.—end note]")
I no longer think it's worth our effort to try to warn people that these footguns are even more footgunnish than the average C++ footgun. I think we should just strike the note.
[specialized.algorithms.general]/3 says that:
However, this is a non-normative note, and maybe sometimes incorrect.
In this example
the newly created
B
object doesn't transparently replace the original base class subobject, and hence the lifetime ofd
is ended by the operation. But the program may still have well-defined behavior, as long as the pointer or reference tod
or its base class subobject is carefully used.The text was updated successfully, but these errors were encountered: