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

@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

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

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

Новые блоги и статьи Все статьи Все блоги /
Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Символьное дифференцирование igorrr37 13.02.2026 / * Программа принимает математическое выражение в виде строки и выдаёт его производную в виде строки и вычисляет значение производной при заданном х Логарифм записывается как: (x-2)log(x^2+2) -. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.
«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL3_image 8Observer8 10.02.2026 Содержание блога Библиотека SDL3_image содержит инструменты для расширенной работы с изображениями. Пошагово создадим проект для загрузки изображения формата PNG с альфа-каналом (с прозрачным. . .

@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