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

@Undisputed · Регистрация: 10.06.2014

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

Вопрос в заголовке темы. Почему? Создается всего 2 объекта, но деструктор вызывается трижды.
Вот пример

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
#include <iostream>
#include <vector>
 
class Foo
{
    public:
    Foo(int n)
    {
        std::cout << "CONSTRUCT" << std::endl;
    }
    ~Foo()
    {
        std::cout << "DESTRUCTED" << std::endl;
    }
};
 
int main()
{
    std::vector<Foo> v;
    v.reserve(2);
    v.emplace(v.begin(), 1);
    v.emplace(v.begin(), 2);
    std::cout << std::endl << v.capacity() << std::endl;//2
}

http://rextester.com/CFBZ76666

Ещё интересует вот что. Если описать деструктор, нужно ли описывать ещё и деструктор по умолчанию? Если нет, то каким образом происходит освобождение памяти, которое было занято для объекта (речь о простых типах)

MrGluck · 18.01.2017, 20:24

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

но хогги пишет что этим занимается деструктор по умолчанию

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

@Undisputed · 18.01.2017, 20:26 **[ТС]**

Croessmah,
Вы так и не ответили на мой вопрос по поводу noexcept

Добавлено через 1 минуту
MrGluck,
Значит происходит невидимое наследование функционала деструктора по умолчанию?)))

@TheCalligrapher · 18.01.2017, 20:39

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

Значит происходит невидимое наследование функционала деструктора по умолчанию?)))

Ну термин "наследование" тут применять не стоит - он зарезервирован в С++ для других целей, но в общем это так. Даже написанный "руками" деструктор все равно втихаря выполняет ряд неявных действий: он неявно вызывает деструкторы подобъектов данного объекта. (А также в популярых реализациях он обычно опционально вызвает оператор освобождения сырой памяти operator delete). Симметричным образом выглядит и ситуация с конструкторами, так что ничего специфичного именно для деструкторов тут нет.

@Fulcrum_013 · 18.01.2017, 20:41

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

За тем, что это могут быть не POD-типы.

Это существенно только для добавления/удаления элементов. Для подвижки и реаллокации неусщественно, т.к. внутреннее состояние объекта не зависит от адреса по которому он располагается в памяти.

@Undisputed · 18.01.2017, 20:43 **[ТС]**

TheCalligrapher,
Т.е говоря про operator delete вы имеете ввиду что деструктор по умолчанию может сам освободить сырую память? Откуда он знает может эта память нам все еще нужна?

@TheCalligrapher · 18.01.2017, 20:50

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

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

Здесь речь идет о каком-то конкретном типе?

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

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

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

Т.е говоря про operator delete вы имеете ввиду что деструктор по умолчанию может сам освободить сырую память? Откуда он знает может эта память нам все еще нужна?

Освобождение сырой памяти выполнятеся только тогда, когда деструктор вызван непосредственно из delete-выражения. Это известно вызывающему коду о чем он сообщает деструктору через скрытый параметр. Ссылки на "ру.стековерфлоу.ком" тут, я смотрю, запрещены, поэтому просто скопирую свой пост оттуда

---

В языке С++ абстрактный алгоритм работы оператора delete сводится к последовательности из двух шагов:

1. Вызов правильного деструктора объекта
2. Вызов правильной функции освобождения "сырой" памяти operator delete(void *).

Функция operator delete(void *), как известно, может замещаться/перегружаться пользователем. Разрешается как замещать глобальный ::operator delete(void *), так и перегружать статическую функцию operator delete(void *) в конкретных классах. При этом спецификация языка требует, чтобы выбор конкретного operator delete(void *) делался так, как будто его поиск (name lookup) делался из деструктора удаляемого объекта.

Например

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
28
29
30
31
32
33
34
35
36
37
    #include <iostream>
    
    struct B
    {
      virtual ~B()
      { 
        std::cout << "B::~B" << std::endl; 
      }
      
      void operator delete(void *p)
      { 
        std::cout << "B::operator delete" << std::endl;
        ::operator delete(p);
      }
    };
    
    struct D : B
    {
      virtual ~D()
      { 
        std::cout << "D::~D" << std::endl; 
      }
      
      void operator delete(void *p)
      { 
        std::cout << "D::operator delete" << std::endl;
        ::operator delete(p);
      }
    };
    
    int main()
    {
      B* pb = new B;
      B* pd = new D;
      delete pb;
      delete pd;
    }

В таком коде при выполнении delete pb после выполнения деструктора B::~B должен вызваться B::operator delete, а при выполнении delete pd после выполнения деструктора D::~D должен вызваться D::operator delete. Другими словами, несмотря на то, что функция operator delete всегда является статическим членом класса, она должна вести себя фактически как виртуальная (!) функция.

Для того, чтобы удовлетворить этому требованию языка, большинство реализаций просто-напросто переносят вызов правильного operator delete внутрь деструктора. Таким образом требуемая "виртуальность" функции operator delete достигается бесплатно, за счет виртуальности деструктора.

При этом понятно, что operator delete(void *) нужно вызвать только для полных объектов, размещенных в динамической памяти, а для остальных объектов - не нужно (т.е. нельзя). Чтобы принять это во внимание, компиляторы снабжают деструктор неявным булевским параметром, говорящим деструктору, надо ли вызывать operator delete. Таким образом в вышеприведенном примере деструкторы на самом деле будут иметь следующий вид

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
      B::~B(bool call_delete)               // неявный параметр
      { 
        std::cout << "B::~B" << std::endl; 
 
        if (call_delete)                    // неявно
          B::operator delete(this);         // неявно
      }
 
      ~D::D(bool call_delete)               // неявный параметр
      { 
        std::cout << "D::~D" << std::endl; 
 
        B::~B(false);                       // неявно
 
        if (call_delete)                    // неявно
          D::operator delete(this);         // неявно
      }

Выражения delete pb и delete pd в такой ситуации превращаются просто в виртуальные вызовы pb->~B(true) и pd->~B(true). Первое попадает в B::~B, второе - в D::~D.

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

@Undisputed · 18.01.2017, 21:07 **[ТС]**

TheCalligrapher,
Постараюсь разобрать ваш пост, спасибо.
А есть актуальные книжки на русском которые помогут хорошо разбираться в таких деталях?

Croessmah · 18.01.2017, 21:10

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

не зависит от адреса по которому он располагается в памяти.

Да ладно? А если объект содержит указатели на свои собственные члены?

@Undisputed · 18.01.2017, 21:13 **[ТС]**

TheCalligrapher,
Разобрался)

@hoggy · 18.01.2017, 21:22

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

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

любые типы пришибаются.

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

MrGluck · 18.01.2017, 21:48

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

Ссылки на "ру.стековерфлоу.ком" тут, я смотрю, запрещены, поэтому просто скопирую свой пост оттуда

Странно, сколько размещал - ни разу не тёрли.
SO - это же не форум даже, а платформа вопрос-ответ.

Croessmah · 18.01.2017, 21:54

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

Странно, сколько размещал - ни разу не тёрли.

Англоязычная версия stackoverflow.com разрешена.
Русскоязычная - запрещена.

@hoggy · 18.01.2017, 21:55

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

Англоязычная версия stackoverflow.com разрешена.
Русскоязычная - запрещена.

шо за дисриминацио?

MrGluck · 18.01.2017, 22:05

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

Англоязычная версия stackoverflow.com разрешена.
Русскоязычная - запрещена.

оО Учитывая, что официальными языками форума являются русский и английский, то какая разница?
Это где-то указано?

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

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

А есть актуальные книжки на русском которые помогут хорошо разбираться в таких деталях?

У Майерса вроде бы это было описано. В правилах про перегрузку операторов new/delete.
Впрочем, вы итак всё это поймёте, поэкспериментировав с написанием пользовательского оператора new для класса.

@Fulcrum_013 · 18.01.2017, 22:16

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

А если объект содержит указатели на свои собственные члены?

Смотря на какие. С указателями на методы при этом ничего не случится.
А если с указателями на члены данных или на самого себя в подобъектах...
То в подавляющем большинстве случаев это говорит о концептуальной кривокостыльности некоторых решений ошибочно считаемых синтаксическим сахаром (например не нативных свойств). Так же в прочем не менее кривая идея хранить подобные объекты в однотипном массиве не допускающем динамического полиморфизма а не хранить массив указателей на них. В любом случае копирование через конструкторы существенно снижает производительность соответственно стоило бы иметь как минимум два типа контейнеров на эту тему (либо средства управления политикой копирования), при этом при внесении в стандарт нативных свойств использование контейнеров с копированием через деструкторы/конструкторы было бы в районе 0% случаев.

Croessmah · 18.01.2017, 23:20

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

То в подавляющем большинстве случаев

Поэтому надо сделать вектор так, чтобы оно не работало?

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

то какая разница?

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

шо за дисриминацио?

Об этом лучше спросить здесь: https://www.cyberforum.ru/abou... 40069.html

@Fulcrum_013 · 18.01.2017, 23:24

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

Поэтому надо сделать вектор так, чтобы оно не работало?

Та он и так пригоден только для хранения тривиальных типов. Потому что не имеет средств взаимодействия с хранимыми элементами.

Croessmah · 18.01.2017, 23:28

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

Потому что не имеет средств взаимодействия с хранимыми элементами.

Потому что ему это не нужно.
Он не для этого предназначен.

P.S. И не надо сейчас писать про "умные" контейнеры в билдере.

@Fulcrum_013 · 19.01.2017, 00:18

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

Потому что ему это не нужно. Он не для этого предназначен.

То бишь быть контейнером нетривиальных типов он не предназначен в принципе, так же как и массивом слабых указателей. При этом хранить объекты в однотипном массиве а не массив указателей на них имеет хоть какой то смысл (обеспечение локальности данных) только пока размер объекта меньше 32 байт. Ну а что касается указателей на члены данных или самого себя - то реальную необходимость в подобных фортелях видел разве что в костыле под названием "не нативная реализации свойств". Т.е. получается в следствии редкости подобных фортелей стоило бы сделать политику реаллокации/подвижек управляемой так же как и политику ресайза.

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

Не по теме:

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

P.S. И не надо сейчас писать про "умные" контейнеры в билдере.

PS: Они там не "умные" а либо массивы слабых указателей либо слабо владеющие

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

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

Потому что ему это не нужно.

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

@TheCalligrapher · 19.01.2017, 00:20

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

Та он и так пригоден только для хранения тривиальных типов. Потому что не имеет средств взаимодействия с хранимыми элементами.

Не имеют? Что за белиберда! Стандартные контейнеры имеют средства взаимодействия со своими элементами, и имеют именно и только те средства взаимодействия со своими элементами, который им нужны для хранения любых типов. Ни о каком "пригоден только для хранения тривиальных типов", разумеется, речи быть не может. Скорее было бы наоборот...

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

Ну а что касается указателей на члены данных или самого себя - то реальную необходимость в подобных фортелях видел разве что в костыле под названием "не нативная реализации свойств".

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

Новые блоги и статьи Все статьи Все блоги /
Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .	Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия	Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .
Калькулятор для расчета родства russiannick 07.08.2026 1. Задача: Создать калькулятор для расчета родства. Родственных связей существует 8 ступеней, такие как: p - отец P - мать q - муж Q - жена b - брат B - сестра s - сын S - дочь	Мир по моей воле kumehtar 07.08.2026 Когда-то кажется, что всё просто. Ты весь такой светлый. Причиняешь добро. Борешься за справедливость в этом тёмном мире. Потом начинаешь замечать одну неприятную вещь. Почти каждый хороший. . .	Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .	У нас сейчас поговорку "Опять 25" нужно переделать на "Опять +35". kumehtar 04.08.2026 С ностальгией вспоминаю времена моего детства, когда у нас и правда +25 - была максимальная температура летом. Раньше +25 °C реально казались вершиной жары, когда можно было весь день пропадать на. . .

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	18.01.2017, 20:26 [ТС]
	Croessmah, Вы так и не ответили на мой вопрос по поводу noexcept Добавлено через 1 минуту MrGluck, Значит происходит невидимое наследование функционала деструктора по умолчанию?))) 0

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	18.01.2017, 20:43 [ТС]
	TheCalligrapher, Т.е говоря про operator delete вы имеете ввиду что деструктор по умолчанию может сам освободить сырую память? Откуда он знает может эта память нам все еще нужна? 0

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	18.01.2017, 21:07 [ТС]
	TheCalligrapher, Постараюсь разобрать ваш пост, спасибо. А есть актуальные книжки на русском которые помогут хорошо разбираться в таких деталях? 0

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	18.01.2017, 21:13 [ТС]
	TheCalligrapher, Разобрался) 0