delete this это нормально?

@pup_kin · Регистрация: 02.03.2024

Студворк — интернет-сервис помощи студентам

Всем привет.
неожиданно родилась такая конструкции

C++
1
2
3
4
5
6
7
void SomeClass::Delete() {
        /* операции по логике 
        некие
       */
        // освобождение памяти
    delete this;
};

Это нормально или говорит о возможных потенциальных проблемах или наоборот?

@Renji · 07.07.2024, 10:37

Сообщение от pup_kin

т.е. верно ли понимаю что неплохо бы создать статический метод для класса который будет создавать объекты?

А потом конструктор спрятать в приват, чтобы, не дай Ктулху, этот объект не создали на стеке. Правда, дабы класс можно было наследовать, конструктор придется делать все же не приватным, а просто защищенным. А protected конструктор можно сделать обратно public, если сделать потомка класса с публичным конструктором. В общем, способ выстрелить себе в ногу в итоге скорее всего найдется.

@Fulcrum_013 · 07.07.2024, 16:49

Renji, а можно operator delete перегрузиь так чтобы определял он в куче сконстрактен или где в другом месте. Ну а вообще да - способов выстрелиь се в ногу мульйон. Один из них юзать гнилые иерархии, которые не соответствуют модели по которой оное ООП спроектировано фунциклить. Эь уже так сразу термоядреным батоном в ногу стрелять

@Not_find · 07.07.2024, 18:07

Данный метод удобно использовать в классе с подсчётом ссылок.

@Fulcrum_013 · 07.07.2024, 18:15

Not_find, Ну что собствено говоря в COM и сделано. Только вот подсчет ссылок - это ни разу не про взаимосвязи ООП.

@eva2326 · 07.07.2024, 18:17

Сообщение от pup_kin

delete this это нормально?

Да.
Данный подход используется для механизмов со встроенным счетчиком ссылок.
Например: intrusive_ptr, технология COM, и тп.

@commun · 07.07.2024, 21:28

Сообщение от pup_kin

delete this это нормально

Это ненормально. Объект создается из внешней среды. Можно только из этого объекта попросить внешнюю среду (если эта среда - начальный объект, из которого произошло создание экземпляра this) произвести удаление. Для это нужно вызвать в этом начальном объекте событие из this. В Аксе это называется "перехват события". Можно пробовать и в С++.

@Renji · 07.07.2024, 21:39

Сообщение от commun

Это ненормально. Объект создается из внешней среды. Можно только из этого объекта попросить внешнюю среду (если эта среда - начальный объект, из которого произошло создание экземпляра this) произвести удаление.

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

@commun · 07.07.2024, 21:45

Да, нужно повозиться. Разговор не о среде, а о ее конкретном объекте (скажем, некий класс). Ничего виртуального. Пусть потеет.

@Fulcrum_013 · 07.07.2024, 22:17

Renji, C учетом что все это нужно все равно хранить и рассылать все те же уведомления для обеспечения более других взаимодействий между объектами (имплементация самой бизнес-логики), то оверхед 0, поэтому такой способ взаимосвязей - агрегация и композиция, в ООП и принят. А с учетом того что использование системы взаимосвязей, принятой в ООП, делает ненужными ни GC ни его эмуляцию на рефкаунтинге, то это еще и снижение оверхеда практически до 0 (особенно на слабых ссылках). Ну и при жизни обджектов в разных адресных просстранствах по другому вообще никак. - т.е. это и есть самоее обычное ООП. А что тама с искоробочными смартами одному коммитету понятно (на самом деле смарты засунули в STL аки имитатор GC для облегчения первокурсникам перехода с жабы).

Кстати так о птичках на таком подходе с оповещениями живут и Qt и VCL и вообще все ООП. Даже та же STL. Как думаете чем занимаются итераторы в деструкторе? Правильно - оповещением контейнера о том что они почили в бозе. А контейнер чем в деструкторе и не только занимается? Да тем же самым - оповещает итераторы что они больше невалидны. Еще раз - выход из скопа объекта живущего на стеке это такой вариант самоудаления.

Добавлено через 28 минут

Сообщение от commun

Можно только из этого объекта попросить внешнюю среду (если эта среда - начальный объект, из которого произошло создание экземпляра this) произвести удаление. Для это нужно вызвать в этом начальном объекте событие из this. В Аксе это называется "перехват события". Можно пробовать и в С++.

Можно и ухо чесать, обматывая руку вокруг головы, можно и зубы удалять через задницу. Но никто в здраом уме этого делать не будет. От попросите вы внешнюю среду. А что для этого надо? Попросить какой то другой объект вычистить все ссылки на этот и удалить его? Управление верется после этого один хрен туда же. Что вы напишите Boss->DeleteMe() что delete this - работу по вычистке подвисающих от этого указателей придется проделать ту же самую. Но в том то и дело что среда не может знать какую именно. А соответственно оной вычисткой должен заниматься сам объект и делать это именно из предназначенного для этого бай дизайн дестркутора. Поэтому все ваши предложения только усложняют жизнь в этом плане и более ничего.
Т.е. на самом деле без разницы где вызван delete - изнутри или извне. Важно чтобы битых ссылок в результате не осталось. А если вычистка ссылок обеспечена в деструкторе, тогда вообще без разницы откуда (деструктор все равно вызовется) и самое главное неважно когда его удалять.

@pup_kin · 08.07.2024, 03:14 **[ТС]**

Сообщение от commun

Это ненормально. Объект создается из внешней среды. Можно только из этого объекта попросить внешнюю среду

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

C++
1
2
3
4
5
6
7
8
9
10
void SomeClass::Delete() {
    std::cout << this << "\n";
    delete this;
    std::cout << "goodbuy cruel world \n";
    std::cout << this<< "\n";
    std::cout << i++<< "\n"; // здесь норм 
        for (int y = 0; y < 1000; y++, i++); // здесь норм
        this->test(); // тут норм
    this->Delete(); // тут уже ошибка 
};

И ,собственно, хотелось понять будет ли это поведение стабильным.
лично мне нравится удалять объект через самого себя

т.е. после delete this срабатывает деструктор.
но при этом поля объекта еще доступны для операций с ними

оказывается можно принудительно вызывать деструктор

@commun · 08.07.2024, 08:30

Да, тупая тема. На Хабре пишут, что в С++ так почти нельзя.
https://habr.com/ru/articles/424593/

@SmallEvil · 08.07.2024, 10:59

Сообщение от pup_kin

оказывается можно принудительно вызывать деструктор

можно, но оставлять существовать такой объект - нельзя.

Добавлено через 15 минут

Сообщение от pup_kin

// тут норм

Там везде уже шляпа.
Вот есть же такие люди которые специально ходят по граблям. И им по кайфу

@pup_kin · 08.07.2024, 19:24 **[ТС]**

Сообщение от SmallEvil

Вот есть же такие люди которые специально ходят по граблям. И им по кайфу

ну в 1С например можно написать

1C
1
2
3
4
5
6
7
8
9
10
ref = catalogs.reference1.findByDescription("тестовое наименование");
if not ref.Empty() then
объект = ref.ПолучитьОбъект();
объект.удалить();
 
// и все удалится, но после этого 
// ref не будет пустой, а будет указывать не несуществующий объект. получить который будет нельзя.
// но объект удаляется сам собой.
 
конецесли;

я например не вижу проблем чтобы не удалять объект своими же методами.
Все равно же придется писать некое апи для объекта.

@SmallEvil · 08.07.2024, 19:32

Сообщение от pup_kin

ну в 1С например можно написать

Так и каким боком тут АдынЭС ?

@DrOffset · 08.07.2024, 20:48

Сообщение от pup_kin

здесь норм

Сообщение от pup_kin

здесь норм

Сообщение от pup_kin

тут норм

То, что C++ это не проверяет и не стучит вам по рукам - не значит, что это "норм".
С++ это не проверяет для исключения неоправданного замедления программы, а не потому что так якобы можно делать.

@pup_kin · 08.07.2024, 21:29 **[ТС]**

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

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

а что вообще происходит в момент delete this?
[наверн надо посмотреть в асмр.]
наверн зависит от компилятора поведение.

@SmallEvil · 08.07.2024, 21:50

pup_kin, delete - противовес new, он не просто вызовет деструктор, если он есть, конечно.
Но так же будет освобождена память которая была выделена с помощью new.
То есть, после delete this, объекта больше нет, и ни одного вызова и доступа к данным больше не должно быть, потому что UB.

Сообщение от pup_kin

**С момента создания темы, я прост поковырялся тоже

Как то вы слабо поковырялись, хоть бы на Стековерфлов зашли, что бы понять слова абзацем выше..

@pup_kin · 08.07.2024, 22:54 **[ТС]**

Сообщение от SmallEvil

Так и каким боком тут АдынЭС ?

адинес прост на си написан, вот я и подумал, что они перенесли концепцию

@Fulcrum_013 · 09.07.2024, 01:22

pup_kin, Операция деинициализации объекта и операция удаления буфера памяти в которой он живет это разные операции. В ситуациях когда память объекта удаляется (delete/выход из скопа/удаление статически содержащего обьекта)деструктор в С++ вызывается автоматически. Именно поэтому вручную его обычно не вызывают особенно после того как появились placement версии new и delete. Ну в общем деинициализация объекта без удаления памяти обычно ессли и нужна то под капотом контейнеров а-ля вектор и вариантных типов имплементирующих динамическую типизацию.

Добавлено через 6 минут

Сообщение от pup_kin

успеет ли объект отработать удаление самого себя

Еще раз по порядку что произойдет после вызова delete:
1. Будет вызван деструктор объекта, потом все деструктора предков по цепочке. С этого момента данные объекта считаются непригодными к чтению - т.е. там типа мусор, а соответсвенно и методы вызывать тоже нельзя.
2. Буфер памяти будет удален - после этого писать в буфер объекта нельзя - считается что память уже может быть переиспользована и запись в нее приведет к разрушению других данных.
3. Управление возвращается на следующий после вызова delete оператор.

Новые блоги и статьи Все статьи Все блоги /
ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Nekobox - outbounds[0].transport: unknown transport type: raw damix 01.10.2026 Фикс ошибки Правым кликом по серверу -> отладочная информация -> edit Заменить "net": "raw", на "net": "tcp", Нажать кнопку reload.	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .
Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .

@Fulcrum_013 2083 / 1576 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	07.07.2024, 16:49
	Renji, а можно operator delete перегрузиь так чтобы определял он в куче сконстрактен или где в другом месте. Ну а вообще да - способов выстрелиь се в ногу мульйон. Один из них юзать гнилые иерархии, которые не соответствуют модели по которой оное ООП спроектировано фунциклить. Эь уже так сразу термоядреным батоном в ногу стрелять 0

@Not_find 0 / 0 / 0 Регистрация: 07.07.2024 Сообщений: 1
	07.07.2024, 18:07
	Данный метод удобно использовать в классе с подсчётом ссылок. 0

@Fulcrum_013 2083 / 1576 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	07.07.2024, 18:15
	Not_find, Ну что собствено говоря в COM и сделано. Только вот подсчет ссылок - это ни разу не про взаимосвязи ООП. 0

@commun 459 / 246 / 15 Регистрация: 29.10.2014 Сообщений: 1,084
	07.07.2024, 21:45
	Да, нужно повозиться. Разговор не о среде, а о ее конкретном объекте (скажем, некий класс). Ничего виртуального. Пусть потеет. 0

@commun 459 / 246 / 15 Регистрация: 29.10.2014 Сообщений: 1,084
	08.07.2024, 08:30
	Да, тупая тема. На Хабре пишут, что в С++ так почти нельзя. https://habr.com/ru/articles/424593/ 0

@pup_kin 16 / 18 / 2 Регистрация: 02.03.2024 Сообщений: 510
	08.07.2024, 21:29 [ТС]
	т.е. если без delete this не будет ли это излишним, привлекать ещё одну сущность для работы с SomeClass? все равно же придется создавать механизм для управления- создания/уничтожения объектов класса? я верно понимаю что если будет нужен функционал аналогичный delete this, то нужна будет новая сущность? просто с точки зрения механики, delete this вообще вызывает деструктор. т.е. ООП его отрабатывает с запасом, т.е. событийность объекта не крашится. Если бы когда делаю delete this деструктор бы не вызывался, тогда да - это явная проблема. **С момента создания темы, я прост поковырялся тоже, и сейчас вообще не вижу причин не использовать delete this. оно везде отрабатывает ровно, кроме рекурсивных вызовов метода с delete this. а что вообще происходит в момент delete this? [наверн надо посмотреть в асмр.] наверн зависит от компилятора поведение. 0

delete this это нормально?

Решение