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

@FasterHarder · Регистрация: 28.04.2015

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

Привет!
Есть класс TVector и есть у него деструктор вот такой:

C++ (Qt)
1
2
3
4
5
6
7
    ~TVector(void)
        {
            delete[] this->data;    // уничтожаем данные
            this->data = NULL;      // не оставляем висячих указателей
     
            this->n = 0;            // данных нет, поэтому кол-во элементов стало равно 0
        }

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

я не оч.выкупил, что требуется, но решил добавить такую проверку в деструкторе:

C++ (Qt)
1
2
3
4
5
6
7
8
9
10
    ~TVector(void)
        {
            if(this->n != 0)
            {
                delete[] this->data;    // уничтожаем данные
                this->data = NULL;      // не оставляем висячих указателей
     
                this->n = 0;            // данных нет, поэтому кол-во элементов стало равно 0
            }
        }

Вопрос: это нужно было сделать с деструктором или нет?) Если нет, то, что??

@hoggy · 26.12.2020, 14:43

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

корректно обрабатывать ситуацию повторного вызова деструктора

корректно - никак.
сама формулировка - за гранью здравого смысла.

вызов деструктора - это смерть объекта.
после того, как деструктор отработал, объект - мёртв.

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

@0x10 · 26.12.2020, 14:43

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

а как можно исключить повторный вызов деструктора?
пример:
this->.~TClass();
this->.~TClass();

Не писать такой код.

@hoggy · 26.12.2020, 14:44

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

this->data = NULL; // не оставляем висячих указателей
this->n = 0; // данных нет, поэтому кол-во элементов стало равно 0

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

@FasterHarder · 26.12.2020, 14:49 **[ТС]**

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

ты осознаешь какой это бред?

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

меня вообще смутило, что в постановке задания докапываются до этого деструктора! у него одна цель: удалить дин.память. Зачем что-то еще морочить с ним)

Добавлено через 52 секунды

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

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

конечно, он же уже мертв и не дышит или на последнем издыхании, т е делает последний выдох в своей жизни

@DrOffset · 26.12.2020, 16:01

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

this->.~TClass();
this->.~TClass();

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

как можно ЭТО исключить?

Очень просто. Вы НЕ должны писать ТАК.

IGPIGP · 26.12.2020, 16:15

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

Вызовется.

Это я и имел ввиду

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

код будет содержать UB, а защита обнулением внутри деструктора от этого не спасет (UB от этого не исчезнет).

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

@hoggy · 26.12.2020, 16:18

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

меня вообще смутило, что в постановке задания докапываются до этого деструктора! у него одна цель: удалить дин.память.

и правильно докапываются.

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

как вообще может так случиться, что объект помер дважды?

C++
1
2
3
4
5
6
7
8
9
10
struct some{};
 
some* ptr;
 
int main()
{
    ptr = new some;
    delete ptr;
    delete ptr; // <--- мы ничайно
}

что бы недопустимть UB, нужно:
- либо просто запретить второй вызов delete
- либо сделать так, что бы второй вызов delete не приводил к смерти объекта

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
struct some{};
 
some* ptr;
 
int main()
{
    ptr = new some;
    delete ptr;
    
    ptr = nullptr;
 
    delete ptr; // <--- уже не навредит
}

но! есть нюанс:
а что, если у нас многопоточная среда?
указатель ptr - глобальный,
а значит доступ к объекту могут получить несколько потоков.

что, если несколько потоков одновременно начнут убивать наш объект?

что бы гарантировать надежность кода,
нужно обеспечить thread-safe защиту для указателя ptr.

сделать это можно самыми разными способами.
есть убер-надежные и элегантные RAII.

я же приведу пример попроще:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <thread>
#include <mutex>
 
struct some {};
 
std::mutex mutex_ptr;
some* ptr;
 
void work()
{
    ::std::lock_guard<std::mutex> 
        lock(mutex_ptr);
    
    delete ptr; 
    ptr = nullptr; // <--- теперь безопасно
}
 
int main()
{
    ptr = new some;
    
    std::thread t1(work);
    std::thread t2(work);
    
    t1.join();
    t2.join();
}

итого:
тщательно осмыслив материал, ты ответишь своему преподавателю:

1.
указатели на динамическую память необходимо обнулять,
с целью предотвратить ущерб от ничайного двойного delete

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

@FasterHarder · 26.12.2020, 16:44 **[ТС]**

что бы недопустимть UB, нужно:
- либо просто запретить второй вызов delete
- либо сделать так, что бы второй вызов delete не приводил к смерти объекта

C++
1
2
3
4
5
6
7
8
9
10
11
12
struct some{};
 
some* ptr;
 
int main()
{
    ptr = new some;
    delete ptr;
    
    ptr = nullptr;
 
    delete ptr; // <--- уже не навредит

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

короче, я пока оставляю деструктор как есть

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

IGPIGP · 26.12.2020, 16:48

Деструктор работает с this а он не может быть сброшен. Он константа)

@DrOffset · 26.12.2020, 16:50

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

такую проверку в деструкторе

Такая проверка на NULL в любом случае не нужна.

Обнуление можете оставить, чтобы удовлетворить требования преподавателя. Но вы должны понимать, что в реальной ситуации делать обнуление не требуется.

@FasterHarder · 26.12.2020, 16:52 **[ТС]**

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

что это в реальной ситуации делать

Макконел рекомендует ВСЕГДА это делать

@DrOffset · 26.12.2020, 16:57

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

Макконел рекомендует ВСЕГДА это делать

Речь об обнулении полей в деструкторе. Макконел рекомендует обнулять поля в деструкторе? Вы уверены, что вы верно поняли, чтобы это утверждать?

@FasterHarder · 26.12.2020, 16:59 **[ТС]**

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

Макконел рекомендует обнулять

любые указатели после того, как они не используются/перестали быть нужны/удалены и пр.

дословно я не помню

@DrOffset · 26.12.2020, 17:04

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

Рекомендации Макконела - это очень хорошо, но если вы не можете различить ситуации, когда они применимы, а когда нет, то толку от них немного.

@0x10 · 26.12.2020, 17:23

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

Деструктор работает с this а он не может быть сброшен. Он константа)

Он не константа, а prvalue.

@hoggy · 26.12.2020, 17:42

Сообщение от 0x10

this

Сообщение от 0x10

Он не константа, а prvalue.

this - всегда константа.
категория доступа через this - всегда lvalue.

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

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

Макконел рекомендует обнулять поля в деструкторе?

не было такого.

@hoggy · 26.12.2020, 18:02

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

твой пример на указателе

да.
потому что ты использовал волшебную фразу:

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

дин.память

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

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

а при тесте это могут вбить в любом месте прогги

на языке с++ существует множество способов, как острелить себе яйца.
и при этом нет возможности реализовать защиту от дурака.

прочитав Макконелла, ты должен был понять,
что защиту нужно делать только от ничайных ошибок.
от откровенных вредителей,
и от дэбилов делать защиту бесполезно.

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

C++
1
2
3
4
5
6
7
8
9
10
struct some 
{
    virtual ~some(){}
    virtual void foo(){}
};
int main()
{
    some* ptr = nullptr;
    ptr->foo();  // <--- uppssss
}

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

Т е намек

плохой ход.
"намеки" - это к гадалкам, к бабкам на лавочке, ну или просто к женщинам.
они любят намеки.

в программировании намёкам места нет.
если что-то не понятно - уточняй сабж у руководства.

@0x10 · 26.12.2020, 18:06

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

this - всегда константа.

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

его действительно правомерно было бы называть константным.
однако это не так. он - prvalue (чисто временный, рожденный как временный объект)

Указатель this, теория

@hoggy · 26.12.2020, 18:22

Сообщение от 0x10

Указатель this, теория

действительно prvalue.
спасибо, что указал мне на мою ошибку.

странно, я вроде бы знаком с теорией.
https://rextester.com/QCYR71969

но все равно, уже не в первый раз наступаю на эти же грабли.
в голове почему то прочно засела мысль,
что this - не_изменяемый указатель.

хотя на самом деле this вообще, строго говоря, указателем не является.
это - выражение.

что-то наподобие такого:

C++
1
template<class t> T* this();

IGPIGP · 26.12.2020, 21:34

Сообщение от 0x10

Он не константа, а prvalue.

0x10, спасибо))) Я давно хочу написать короткое эссе о прикладом математизме в предметной области. Я постоянно пишу об этом, но как сказал поэт:

Трудно петь о горах,
Если знаешь, что спето немало,
Но труднее не петь,
Если знаешь, что спето не всё

Вначале было значение, и значение было у ссылки, и значение было ссылка.
Ибо сказано: I am - Pointer!
Историю о ссылках и категориях значений от времен ~~язычества~~я зыка С я предлагаю посмотреть тут:
https://en.cppreference.com/w/... e_category
Размывание границ первоначально очерченных абстракции - путь из знания в религию. Часто можно видеть, как молодой послушник получив очередное наставление с сакральным знанием, в экстазе восклицает

"О спасибо тебе брат мой! Я слышу Голос! "

А в ответ

Чиста твоя вера брат и рвение твоё похвально. Но у prvalue нет голоса. Ты ещё многое узнаешь, -юный падаван.

Так и живём.
От себя добавлю:

Each C++ expression (an operator with its operands, a literal, a variable name, etc.) is characterized by two independent properties: a type and a value category.

То есть this как и много другое, в зависимости от контекста, это
- английское слово
- ключевое слово языка
- выражение имеющее категорию значения
- программный объект имеющий тип
Вот ещё ссылка
https://www.ibm.com/support/kn... plr035.htm
в частности

The type of the this pointer for a member function of a class type X, is X* const. If the member function is declared with the const qualifier, the type of the this pointer for that member function for class X, is const X* const.

IBM - фирма, которую мы знаем по многим штуковинам начиная от процессоров и заканчивая серверами. В основе MS-DOS (и др. OS) лежит IBM-DOS и биос-расширения. И то что мы знаем - вершинка айзберга, работающего на заказы минобороны USA и NASA. У этих людей нет времени на песнопения и хождения с хоругвями.
Хотелось бы добавить, что в моей коротенькой фразе

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

Деструктор работает с this а он не может быть сброшен. Он константа)

Смысл вполне ясен и уточнения не требует.
Сказанное мною, - сказано не в обиду, а скорее от избытка чувств)
Поздравляю, всех вас с наступающим Новым Годом, братия во крестах!!!

Новые блоги и статьи Все статьи Все блоги /
Установка нескольких штампов электронной подписи в строго определенных местах файла docx ВладимирСамохин 19.07.2026 (В!) Работа с Электронной подписью - это неотъемлемая часть современного документооборота. Но что делать, если нужно поставить несколько штампов электронной подписи в строго определенных местах. . .	сукцессия 35. Научная статья о проделанной работе anaschu 19.07.2026 Написал в формате латекс и пдф	Вангую, что это не пройдёт модерацию, и на неделе я запущу свой сервер. Hrethgir 19.07.2026 Эта публикация сейчас в песочнице и ждёт приглашения. https:/ / habr. com/ ru/ sandbox/ 295048/ начало и оглавление - Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование. . .	сукцессия 33. открытые вопросы от клауде anaschu 19.07.2026 "Что накопилось за эту часть А — тринадцать правок, из которых шесть пришли из ваших вопросов и каждая оказалась реальной ошибкой, а не калибровкой: односторонний симбиоз, отсутствующий листопад,. . .
32 сукцессия anaschu 19.07.2026 сукцессия 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не «подкручивает» сходимость —. . .	сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических anaschu 18.07.2026 Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .	сукцессия 30. Массив проверяющих друг друга моделей anaschu 18.07.2026 Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0) Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона Уважаемые коллеги! В продолжение. . .	Грибы - это женщины, деревья - это мужчины. Анти инь янь для союза мужчины и женщины. anaschu 18.07.2026 ГЛАВНЫЙ НАУЧНО-ФИЛОСОФСКИЙ ВЫВОД: Сексуально-Репродуктивный Капитализм против Государства Моногамии Коллеги, мы вышли на финишную прямую 20-мерного ОДУ-моделирования вековой сукцессии (ветка. . .

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 9007 / 4708 / 630 Регистрация: 04.12.2011 Сообщений: 14,003 Записей в блоге: 16
	26.12.2020, 16:48
	Деструктор работает с `this` а он не может быть сброшен. Он константа) 0

@DrOffset 19501 / 10106 / 2461 Регистрация: 30.01.2014 Сообщений: 17,825
	26.12.2020, 17:04
	FasterHarder, эта рекомендация касается объектов, время жизни которых еще не закончено, но логически они уже не используются. После выполнения деструктора время жизни всех полей заканчивается: их больше не существует и совершенно не важно какое у них значение, потому любое обращение несуществующему объекту приводит к UB. Рекомендации Макконела - это очень хорошо, но если вы не можете различить ситуации, когда они применимы, а когда нет, то толку от них немного. 0