Краткий ответ

delete this немедленно завершает время жизни текущего объекта и освобождает его память. После этого нельзя обращаться к его полям, вызывать методы, повторно удалять объект или передавать указатель дальше как действительный; даже чтение указателя допустимо только как значения указателя, но не как объекта.

Такой приём корректен лишь при строгих условиях: объект создан способом, совместимым с delete, не является подобъектом или объектом автоматического хранения, а вызывающий код действительно передал исключительное владение. В современном коде предпочтительнее явно управлять временем жизни через std::unique_ptr или отдельный метод-владелец.

Исторический контекст

До широкого применения RAII объекты иногда самостоятельно управляли своим временем жизни: например, при ручном подсчёте ссылок объект удалял себя, когда последний владелец сообщал об освобождении ссылки. delete this позволяло реализовать такой протокол без отдельной функции удаления.

RAII и умные указатели обычно устраняют необходимость в этом приёме: владелец ресурса становится явным, а уничтожение выполняется деструктором владельца. Поэтому delete this сейчас рассматривают как специализированный низкоуровневый механизм, а не как обычный способ освобождения объекта.

Постановка проблемы

После delete this указатель, через который был вызван метод, становится висячим. Опасность особенно высока, если метод продолжает выполнять код после удаления: любое обращение к нестатическому полю или вызов нестатического метода использует уже завершивший жизнь объект.

Неверно применять этот приём к объекту на стеке, к члену другого объекта, к элементу массива или к памяти, полученной placement new. Нельзя также использовать его для объекта, которым владеет std::shared_ptr: умный указатель позднее попытается удалить тот же объект повторно.

Подробное решение

Выражение delete this вызывает деструктор текущего объекта, а затем освобождает память через соответствующий механизм удаления. После завершения операции объект больше не существует, поэтому метод должен немедленно завершить работу и не использовать this.

Минимальный допустимый по форме сценарий выглядит так:

class SelfDestroying {
public:
    void release() {
        delete this;
    }

private:
    ~SelfDestroying() = default;
};

void use() {
    auto* object = new SelfDestroying;
    object->release();
}

Здесь деструктор закрыт, поэтому удалить объект можно только через предусмотренный интерфейс. Но даже этот пример требует, чтобы объект всегда создавался через new и чтобы после release() никто не использовал исходный указатель.

Для корректности должны одновременно выполняться следующие условия:

объект создан динамически с совместимым способом освобождения;
он не является подобъектом, членом другого объекта или частью массива;
у объекта нет другого независимого владельца;
после удаления метод не обращается к состоянию объекта;
вызывающая сторона знает, что указатель стал недействительным.

Если объект владеется std::unique_ptr, удаление через delete this оставит умный указатель с висячим значением, и его последующий деструктор выполнит повторное удаление. Для совместного владения через std::shared_ptr проблема ещё серьёзнее: объект должен уничтожаться control block, а не самостоятельно.

Безопаснее передать владение объектом функции или методу, который уничтожает его после завершения операции. Если требуется ручное управление временем жизни, обычно используют явный протокол вроде release() у владельца, не позволяя самому объекту скрыто удалять себя.

Ситуация из практики

В старом подсчёте ссылок метод уменьшает счётчик владельцев и при достижении нуля выполняет delete this. Плюс такого решения — компактный протокол: последний освободивший ссылку автоматически уничтожает объект. Минусы — сложное доказательство отсутствия последующих обращений, риск двойного удаления и плохая совместимость с современными владельцами.

Вариант с std::shared_ptr безопаснее для совместного владения: последний владелец уничтожает объект через control block. Его недостатки — стоимость control block, атомарные операции в потокобезопасных сценариях и риск циклического владения.

Если владение единственное, выбранное решение — std::unique_ptr. Он явно показывает владельца, автоматически уничтожает объект при выходе из области видимости и делает передачу владения проверяемой на уровне типов. В результате исчезает необходимость в delete this, а ошибки использования после удаления становятся существенно менее вероятными.

Что кандидаты часто упускают

Можно ли безопасно вызвать delete this, если после вызова метод сразу возвращает значение?

Да, сам возврат значения может быть безопасен, если значение вычислено до удаления либо не требует обращения к объекту после delete this. Но нельзя возвращать ссылку или указатель на часть объекта: они станут недействительными вместе с объектом. Также нельзя вычислять выражение возврата через нестатическое поле после удаления.
Что изменится, если объект удаляется через базовый указатель?

Для delete this критично, какой именно тип удаляется и доступен ли корректный деструктор. Если удаление производится через указатель на базовый класс, деструктор базового класса должен быть виртуальным, иначе уничтожение производного объекта через базовый интерфейс приводит к неопределённому поведению. Само наличие delete this не устраняет требования полиморфного удаления.
Почему проверка, что счётчик ссылок равен нулю, не всегда делает self-destruction безопасным?

Счётчик может защищать только соглашение о владении, но не исключает уже выполняющийся метод, отложенную работу, необновлённый сырой указатель или гонку между потоками. В многопоточном коде уменьшение счётчика должно быть синхронизировано, а отсутствие владельцев ещё не гарантирует отсутствие текущего доступа к объекту. Поэтому одного условия нулевого счётчика недостаточно: требуется доказать корректность всего протокола времени жизни.