примере на тему storage-reuse и transparent-replaceability class-type объектов, в общем случае является очень плохой, поскольку привносит в окружающий код недиагностируемую и недекларируемую зависимость от использования std::launder(), несоблюдение которой приводит к неопределенному поведению?
Упрощенный стандартный сниппет:
struct C {
int i;
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
}
return *this;
}
Кастомное расширение:
struct D: C
{
const D& operator=( const D& other )
{
C::operator=(other);
return *this;
}
};
Контекст использования (предполагающий существование полностью доброкачественных объектов d1 и d2 типа D):
C& c{d1};
d1 = d2;
c.i;
1. c является ссылкой на base-class subobject типа C в пределах d1.
2. storage-reuse в C::operator= в пределах D::operator= был выполнен относительно potentially-overlapping subobject'а.
3. transparent-replaceability не удовлетворено, c отвязана от d1, c.i приводит к неопределенному поведению.
я с вами согласен
Кажется, захотелось что-то вроде [[reuses_storage]] и, кажется, хотеть бесполезно. Буду иметь в виду, спасибо.
ну это должно быть гарантированным поведением
Либо так, но сходу не представлю, что мешает.
как это поможет? слайсинг же все равно происходит
А там дело, кажется, не в слайсинге. В тех же условиях: C* c{&d1}; d1 = d2; std::launder(c).i; Должно быть well-formed.
Обсуждают сегодня