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

@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
            }
        }

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

@FasterHarder · 26.12.2020, 12:50 **[ТС]**

Сообщение от oleg-m1973

лишние действия

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

Хотелось бы получить окончательное резюме и закрыть тему.
Но как я понимаю, что все норм было изначально. Наверное)

а что задание. Соорудить класс одномерный массив и перегрузить его по максимуму + все возможные конструкторы и все.

IGPIGP · 26.12.2020, 12:52

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

Я не понимаю, что означает «placement new будет на другом объекте».

То что на каждом объекте будет вызван свой деструктор. Не будет повтора с формальной точки зрения. Но. 0x10, когда я впервые узнал что реинициализация старой памяти вызовом деструктора и плейсмента создаёт Новый объект, я спорил до хрипоты, плакл и даже бодался. Забили цитатами из стандарта. То есть, в душЕ я с вами) А комететчики в дУше.

@oleg-m1973 · 26.12.2020, 12:53

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

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

Я вроде и не говорил, что полностью. Одна строчка точно была осмысленной.

@FasterHarder · 26.12.2020, 12:54 **[ТС]**

Сообщение от oleg-m1973

Одна строчка точно была осмысленной.

как минимум 4ре, хотя С++ допускает все записать в одну строку, таки да, ты мне сможешь доказать, что только 1а строка имела смысл

@oleg-m1973 · 26.12.2020, 12:55

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

Хотелось бы получить окончательное резюме и закрыть тему.

Резюме - в деструкторе бесполезно делать защиту от повторного вызова. Поэтому в нём её делать не надо.

IGPIGP · 26.12.2020, 13:06

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

прожка у меня не падает вообще,

Так вы же защитились от поломки кучи и снизили вероятность падения. Хотя не всё что выполняется при вызове деструктора, это то что вы пишете в деструктор. Система та генерит ещё что-то. Вот это

Сообщение от oleg-m1973

Если они есть, то в самом деструкторе уже бесполезно от этого защищаться, там будет куча других проблем

об том.

Сообщение от oleg-m1973

Ну а ФУНДАМЕНТАЛЬНО - ты можешь заниматься в деструкторе любым идиотизмом.

Исключения выбрасывать. С формальной точки зрения, если есть исключение, то когда объект выходит из употребление, то исключение можно тоже выбросить. Это да)

Добавлено через 5 минут
oleg-m1973, чтобы мы не говорили о "разных" объектах в одной памяти но мысль 0x10, мне хочется проверить. Представь что вручную вызван деструктор, а плейсмент нью кинул экзепшн. При выходе из области будет повторный вызов деструктора или нет? Если гарантировано, - нет, то мы тут правы и защита не нужна. А если не гарантировано? Тогда всё плохо кончится.

@FasterHarder · 26.12.2020, 13:08 **[ТС]**

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

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

а как именно я защитился? что вы имеете в виду?

IGPIGP · 26.12.2020, 13:10

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

что вы имеете в виду?

проверка - триггер со сбросом указателя и проверкой указателя на ноль.

@FasterHarder · 26.12.2020, 13:10 **[ТС]**

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

Исключения выбрасывать.

кстати, очень точно подмечено!
программка должна все обрабатывать на исключениях. Я не стал говорить это сразу, т к не посчитал это нужным)

@oleg-m1973 · 26.12.2020, 13:19

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

oleg-m1973, чтобы мы не говорили о "разных" объектах в одной памяти но мысль 0x10, мне хочется проверить. Представь что вручную вызван деструктор, а плейсмент нью кинул экзепшн. При выходе из области будет повторный вызов деструктора или нет? Если гарантировано, - нет, то мы тут правы и защита не нужна. А если не гарантировано? Тогда всё плохо кончится.

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

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

Сообщение от oleg-m1973

Представь что вручную вызван деструктор, а плейсмент нью кинул экзепшн

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

IGPIGP · 26.12.2020, 13:19

Сообщение от oleg-m1973

Лично предпочитаю считать все деструкторы помеченными как noexcept (по-моему, так и есть, но, в любом случае, мне так лучше спится), поэтому стараюсь делать так чтоб исключений в них не было.

Про исключение в деструкторе это стёб был. А то что ты процитировал, относится к конструктору (плесмент его вызовет), а в нём сам бог велел выделять ресурсы и кидать исключения.
Ещё раз

C++
1
2
3
4
5
6
7
8
{
ClassResorsesOwner obj(args...); //выделил
//поработал
obj.~ClassResorsesOwner (); очистился
new (&obj)  ClassResorsesOwner (otherArgs...); //tgrow!!!
 
 
//тут вызовется ~ClassResorsesOwner () ?? автоматом ??

@oleg-m1973 · 26.12.2020, 13:23

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

Ещё раз

Ну, тупо не нужно так делать и всё. Как я уже говорил

Сообщение от oleg-m1973

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

IGPIGP · 26.12.2020, 13:23

Сообщение от oleg-m1973

Не существует защиты от идиотов.

oleg-m1973, вот тут не нужно обобщать. Не все такие как я. Есть же и умные люди. Они бывает пользуются пулами памяти выделяемой отдельно, а инициализируемой - отдельно. Не всегда RAII это хорошо (повторное выделение на куче мелких объектов - медленно).

@oleg-m1973 · 26.12.2020, 13:33

Вернее, защита от идиотов слишком дорого стоит

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

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

oleg-m1973, вот тут не нужно обобщать. Не все такие как я. Есть же и умные люди. Они бывает пользуются пулами памяти выделяемой отдельно, а инициализируемой - отдельно.

Да я не обобщаю. Просто "умные люди" обычно вызывают деструкторы вручную только для неинициализированной памяти, массива байтов, для которой они перед этим вызвали placement new. В иных случаях пользуются move-copy конструкторами. Как раз для того, чтоб деструктор не был вызван дважды.

Добавлено через 4 минуты
С таким же успехом можно делать защиту от двойного вызова конструктора. Это ж не си-шарп, здесь можно много всякой хрени сделать. Но можно и не делать.

@DrOffset · 26.12.2020, 14:01

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

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

Не ломается. Потому, что там есть еще слово "одновременно".

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

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

прожка у меня не падает вообще

Это не является в С++ достаточным условием, чтобы считать, что в программе нет ошибок.

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

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

Но как я понимаю, что все норм было изначально.

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

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

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

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

хорошее уточнение
поскольку деструктор вызывается АВТОМАТИЧЕСКИ, то вручную никак + мне еще раньше пояснил один спец, что даже при перегрузке операции присваивания деструктор вручную не вызывается

ответ: получается вручную НИГДЕ не планирую. А разве надо?)

@DrOffset · 26.12.2020, 14:16

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

тут вызовется ~ClassResorsesOwner () ?? автоматом ??

Вызовется.
Если мы пишем такой код, то мы должны гарантировать, что исключений в конструкторе, который вызовется при выполнении placement new не будет. Если же этого не гарантировать, то код будет содержать UB, а защита обнулением внутри деструктора от этого не спасет (UB от этого не исчезнет).

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

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

получается вручную НИГДЕ не планирую. А разве надо?)

Если не знаете зачем, значит не надо.
И тогда получается, что если вручную вызывать не надо, то в вашем деструкторе часть операций лишняя. Т.е. достаточно так:

C++
1
2
3
4
    ~TVector(void)
    {
        delete[] this->data;    // уничтожаем данные
    }

1) Вы можете проверить data на NULL, но это уже делается внутри delete[] (точнее delete[] гарантированно корректно ведет себя при передаче ему NULL-указателя), поэтому проверка не имеет смысла.
2) Вы можете обнулить поля, после вызова delete[], но в программе не может быть корректной ситуации, когда это обнуление сыграет какую-либо роль. Да, при вызове placement new и генерации исключения в нем, и если внутри конструктора не успели еще задать для data какое-то отличное от NULL значение, то в деструкторе, при наличии обнуленного заранее data, вы не упадете, но это не решит проблему, а только замаскирует ее. Если в программе есть проблема, но программа никак об этом не сообщает, то это очень плохо.

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

DrOffset, а по самому стартовому вопросу в сообщении №1 можете что-то дополнить ключевое?
на данный момент получается, что то требование (СИНИМ выделено в 1 сообщении) является бессмысленным? или все-таки нет?

@DrOffset · 26.12.2020, 14:26

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

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

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

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

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

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

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

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

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

чтобы исключить повторный вызов деструктора

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

можно продолжить при желании и даже зациклить)

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

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@FasterHarder 383 / 280 / 112 Регистрация: 28.04.2015 Сообщений: 1,726
	26.12.2020, 14:20 [ТС]
	DrOffset, а по самому стартовому вопросу в сообщении №1 можете что-то дополнить ключевое? на данный момент получается, что то требование (СИНИМ выделено в 1 сообщении) является бессмысленным? или все-таки нет? 0