Добрый день! Коллеги, не подскажите, плиз, насколько валиден код с прямым

вызовом деструктора в конструкторе, вот в таком духе:

struct Foo {
…
Foo() {
if (…) {this->~Foo(); }
}
};


Имею стойкое ощущение, что это UB по причине неначатого лайфтайма, но в Стандарте не нашел четкого пояснения по этому поводу (кроме пункта 18 в [class.dtor])
> Once a destructor is invoked for an object, the object’s lifetime ends; the behavior is undefined if the destructor
is invoked for an object whose lifetime has ended

в котором речь все-таки идет об объекте с _законченным_ врмененем жизни. Не подскажете, есть ли где-то более четкая формулировка?

Не UB, но очень легко отстрелить себе ногу. Никогда так не делайте

я и не хочу, пытаюсь обосновать коллегам почему так делать нельзя. Пока не нашел, но вдруг кто-то уже разбирался подробнее

Если так важно деинициализировать при неправильном вводе, то выбросьте ексепшн, чтобы ЯП сам вызвал деструктор

UB, 100%

1) явно вызывать деструктор нельзя , разве что объект создан через placement new 2) жизненный цикл объекта начинается с открывающейся { тела конструктора (если оно есть , конечно),

1) Можно, главное не забыть после вызова деструктора сделать placement new.

Ну, тут его нет...

похоже что все не так просто, насчет аргумента 1 я как раз нашел опровержение, пример из [basic.life] : 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

НЕ знаю, что там в стандарте на эту тему, но это дичь.

Вне зависимости от того, насколько это валидно, пожалуйста, не делай так

я задавал вопрос с надеждой, что местные душнилы укажут пункт в стандарте, вместо этого почему-то все только говорят, что это плохо 🙂

Он растовик, ща методичка пойдёт

Sergey

Я читал, да: скорее всего опубликую issue по этому поводу, оно родственно CWG2757, там скорее всего нормативная проблема (их немало в этих областях). @allcreater

Нужно, чтобы это было плохо по стандарту просто)

Ну там про деаллокацию вроде, а не вызов деструкторы

Остальные родственные проблемы так и предложили решать. Здесь остается только напомнить, что есть еще один способ их создавать - этот =)

Еще раз спасибо! ничего себе какие лютые бывают кейсы. Такого, чтоб вообще хоть кто-то пытался удалить this в конструкторе, еще не видел, но да, похоже что нормативная база не помешает и для такого 🙂

Оказывается, в CWG2757 в самом примере буквально такой случай показан, просто в вординг забыли занести это, видимо. struct S { constexpr S() { this->~S(); } constexpr S(int) {} }; constexpr int f() { S s(0); s.~S(); std::construct_at(&s); // #1 return 0; } constexpr int x = f(); // error: undefined behavior at #1 during constant evaluation Спецификация очень страдает от отсутствия формальной верифицируемости. В сущности она консистентна ровно на столько, насколько ее удастся толпой вычитать. И работает это так себе, насколько я могу судить.

@allcreater, вординг поправили.