Явный вызов деструктора

Простой поиск подтвердил, что явный вызов деструктора для автоматизированного объекта опасен, так как второй вызов (когда объект выходит за пределы области видимости) имеет неопределенное поведение.

Это правда. Неопределенное поведение вызывается, если вы явно уничтожаете объект с автоматическим сохранением. Подробнее об этом.

Так что мне повезло с моим компилятором (VS 2017) или с этой конкретной программой.

Я бы сказал, что вам не повезло. Лучшее (для вас, кодера), что может случиться с UB, — это сбой при первом запуске. Если он работает нормально, сбой может произойти 19 января 2038 года в рабочей среде.

Текст просто неверен об ошибке времени выполнения? Или действительно часто возникает ошибка времени выполнения? Или, может быть, мой компилятор реализовал какой-то механизм защиты от подобных вещей?

Да, текст какой-то неправильный. Неопределенное поведение не определено. Ошибка во время выполнения — это только одна из многих возможностей (включая носовых демонов).

Полезно прочитать о неопределенном поведении: Что такое неопределенное поведение?

Нет, это просто неопределенное поведение из проекта стандарта C++ [class.dtor]p16:

Как только для объекта вызывается деструктор, этот объект больше не существует; поведение не определено, если деструктор вызывается для объекта, время жизни которого закончилось ([basic.life]). [ Пример: если деструктор для автоматического объекта вызывается явно, а затем блок покидает таким образом, который обычно вызывал бы неявное уничтожение объекта, поведение не определено. — конечный пример

и мы можем видеть из определения неопределенного поведения:

поведение, для которого этот документ не устанавливает никаких требований

У вас не может быть никаких ожиданий относительно результатов. Это могло вести себя таким образом для автора на их конкретном компиляторе с определенными параметрами на конкретной машине, но мы не можем ожидать, что это будет переносимый или надежный результат. Хотя бывают случаи, когда реализация пытается получить конкретный результат, но это просто еще одна форма приемлемого неопределенного поведения.

Кроме того, [class.dtor]p15 дает больше контекста в нормативном разделе, который я цитирую. над:

[ Примечание. Явные вызовы деструкторов нужны редко. Одно из применений таких вызовов — для объектов, размещенных по определенным адресам, с использованием нового выражения размещения. Такое использование явного размещения и уничтожения объектов может быть необходимо для работы с выделенными аппаратными ресурсами и для написания средств управления памятью. Например,

void* operator new(std::size_t, void* p) { return p; }
struct X {
  X(int);
  ~X();
};
void f(X* p);

void g() {                      // rare, specialized use:
  char* buf = new char[sizeof(X)];
  X* p = new(buf) X(222);       // use buf[] and initialize
  f(p);
  p->X::~X();                   // cleanup
}

— конец примечания ]

Текст просто неверен об ошибке времени выполнения?

Это неверно.

Или действительно часто возникает ошибка времени выполнения? Или, может быть, мой компилятор реализовал какой-то механизм защиты от подобных вещей?

Вы не можете этого знать, и именно это происходит, когда ваш код вызывает Undefined Behavior< /а>; вы не знаете, что произойдет, когда вы его выполните.

В вашем случае вам (не)повезло^*, и это сработало, а у меня это вызвало ошибка (двойной бесплатный).

_{*Потому что, если бы вы получили ошибку, вы бы начали отладку, иначе, например, в большом проекте, вы могли бы ее пропустить...}