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

@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

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

@Fulcrum_013 · 19.01.2017, 00:46

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

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

Это лишь реальная причина не пользовать ни vector ни прочую муть из набора STL которая имеет все что не нужно вместо того что реально необходимо контейнерам и указателям при правильном проектировании иерархии

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

Который им нужны для хранения любых типов

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

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

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

Стандартные контейнеры имеют средства взаимодействия со своими элементами

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

@Renji · 19.01.2017, 11:50

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

либо средства управления политикой копирования

Они есть, называются std::is_trivially_copyable. Пингуй себе тривиальность копирования, да переключайся с копирования через memcpy на копирование циклом. Другой вопрос - пользуется ли этим ваша реализация STL.

@Undisputed · 19.01.2017, 16:29 **[ТС]**

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

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

Как заместить глобальный ::operator delete(void *) не нашел. Можете показать пример? Так же интересно зачем это может понадобится. Наверное для выделения памяти со специфичным выравниванием?

При замещении судя по всему прежний ::operator delete(void *) уже потеряется?

MrGluck · 19.01.2017, 16:42

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

Наверное для выделения памяти со специфичным выравниванием?

Подробности есть у Майерса.
Мы может специализировать операторы работы с дин. памятью когда хотим оптимизировать работу с памятью. Дело в том, что new (new[]) старается быть максимально универсальным, само собой чем-то приходится жертвовать.

@Renji · 19.01.2017, 16:43

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

Так же интересно зачем это может понадобится.

Как зачем? В своей программе на десять строчек вы вызываете стандартный глобальный operator new и получаете компактный exe-файл всего на сто (триста, 100500) килобайт. Потому что вместе с одной функцией operator new, вам прилинковали всю стандартную библиотеку. А ~~возможности~~ потребности линковать код одной функции у вас нет, потому что ~~авторам компилятора в лом~~ мужик, ну ты же не по диалапу программу распространять будешь? Ну вот и не занимайся крохоборством.

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

@Undisputed · 19.01.2017, 16:46 **[ТС]**

MrGluck,
Я чушь написал)) Думал об operator new а писал про delete)) Он ж ничего не выравнивает

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

Дело в том, что new (new[]) старается быть максимально универсальным, само собой чем-то приходится жертвовать.

А в чем универсальность?

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

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

В своей программе на десять строчек вы вызываете стандартный глобальный operator new

Не понял как operator new связан с экзешником?

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

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

В своей программе на десять строчек вы вызываете стандартный глобальный operator new

Не понял как operator new связан с экзешником?

@Renji · 19.01.2017, 16:54

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

Не понял как operator new связан с экзешником?

Исполняемый файл вызывает operator new -> компилятор добавляет в исполняемый файл код реализующий operator new->exe-файл становится тяжелее. Очень сильно тяжелее, так как добавлять только код используемой функции не в моде. Когда-то это было оправдано экономией времени компиляции (компилировать стандартную библиотеку долго, лучше готовый шмат кода возьмем), сейчас геморрой один.

@Undisputed · 19.01.2017, 16:59 **[ТС]**

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

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

не допёр

а что ещё нужно добавлять кроме кода используемой функции, в данном случае operator new?

MrGluck · 19.01.2017, 17:11

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

А в чем универсальность?

Данные сразу затираются. Выделение идёт под каждый объект отдельно. Никаких доп. действий.
При перегрузке оператора new:
Можно вместо освобождения памяти, закешировать указатель на участок и потом записывать туда новый объект.
Можно выделять память сразу под несколько объектов.
Можно логировать выделение/освобождение, накладывать дополнительные проверки.
Кроме того, стандартный new может выделять под объекты чуть больше памяти, чем требуется. Иногда это не подходит для ряда задач.

@Renji · 19.01.2017, 17:16

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

не допёр а что ещё нужно добавлять кроме кода используемой функции, в данном случае operator new?

Добавить надо только понятный процессору машинный код operator new. Но этого кода у компилятора нет. Есть только заранее запасенный монолитный шмат машинных кодов, где-то внутри которого затерялся operator new. Отделить от этого шмата код одной функции компилятор не может (из-за потенциальных зависимостей от шмата), а потому весь шмат и цепляет.

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

@Undisputed · 19.01.2017, 17:23 **[ТС]**

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

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

Так собственные аллокаторы никто не отменял

Можно же ими обойтись

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

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

Тоже можно собственным аллокатором

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

Можно логировать выделение/освобождение, накладывать дополнительные проверки.

Тоже можно собственным аллокатором

Т.е не перегружать new а создать просто отдельную сущность - аллокатор

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

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

Можно пожалуйста подробнее?
Зачем ему выделять больше памяти?
Где это может не подойти за исключением того то памяти жалко

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

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

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

Спасибо! Я правильно понимаю, это делает программу медленнее?

@Renji · 19.01.2017, 17:29

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

Спасибо! Я правильно понимаю, это делает программу медленнее?

Нет, только жирнее из-за обилия недостижимого кода. А так, этот код, при современных механизмах отображения файлов в память, даже оперативной памяти занимать не должен (нет обращений->не подгружается с диска). Но все равно не особо приятно когда такой мусор фактически занимает этак половину небольшого exe-шника.

MrGluck · 19.01.2017, 17:30

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

Можно пожалуйста подробнее?

Я уже в третий раз пишу - подробнее рассмотрено в книге у Майерса.

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

можно собственным аллокатором

Аллокатор пишется для контейнеров. Мы же перегружаем new для классов, таким образом, контролируем выделение памяти для объектов класса, неважно в чём они лежат.

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

Зачем ему выделять больше памяти?

Например потому, что удобнее выделять память блоками определённых размеров. И никто не запрещает ему выделить больше памяти.

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

Где это может не подойти за исключением того то памяти жалко

Там, где мы последовательно перебираем блоки определённых размеров в памяти.

@Undisputed · 19.01.2017, 17:39 **[ТС]**

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

Аллокатор пишется для контейнеров.

В смысле для контейнеров? Имеется ввиду STL?
Аллокатор вроде бы должен просто предоставлять доступ к памяти по определенной стратегии думаю не важно контейнеры используют эту память или кто то другой

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

Там, где мы последовательно перебираем блоки определённых размеров в памяти.

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

Добавлено через 2 минуты
Renji,
В целом понял, спасибо
Только не очень понял зачем все таки компиляторам требуется этот дополнительный код (с точки зрения реализации)

@GbaLog- · 19.01.2017, 17:50

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

Зачем ему выделять больше памяти?

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

@Renji · 19.01.2017, 17:56

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

Зачем ему выделять больше памяти?

Например, для buddy memory allocation. Очень шустро, но весьма значительная часть доступной памяти вылетает в трубу.

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

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

С точки зрения реализации, компилятор обрабатывает каждый cpp независимо и получает из него отдельный шмат кода. А линкер потом просто склеивает эти шматы вместе. При этом компилятор понятия не имеет используется ли этот шмат в принципе (он же в соседние cpp не смотрит), а линкер понятия не имеет как отделить нужное от ненужного.
Теперь компилятор и линкер вроде как стали умнее, но схема "зачем голову забивать? Прилепим готовый шмат и дело с концом" продолжает жить.

MrGluck · 19.01.2017, 17:58

Сообщение от GbaLog-

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

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

@Fulcrum_013 · 19.01.2017, 17:59

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

Как заместить глобальный ::operator delete(void *) не нашел. Можете показать пример? Так же интересно зачем это может понадобится. Наверное для выделения памяти со специфичным выравниванием?
При замещении судя по всему прежний ::operator delete(void *) уже потеряется?

Глобальный никак. Толь для каждого отдельно взятого типа.
Из C++ Language Reference

The global operators, ::operator delete(), and ::operator delete[]() cannot be overloaded. However, you can override the default version of each of these operators with your own implementation. Only one instance of each global delete function can exist in the program.

@GbaLog- · 19.01.2017, 18:04

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

Это не нужно нигде хранить.

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

@Fulcrum_013 · 19.01.2017, 18:22

Сообщение от GbaLog-

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

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

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

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

чушь написал)) Думал об operator new а писал про delete)) Он ж ничего не выравнивает

Обычно их нужно создавать парой. Причем применение может быть разным. Например реализация пула объектов. Или выделение памяти не в системном озу а к примеру аки буфера DirectX живущего в видеокарте. В общем своя реализация менеджера кучи реализующего альтернативную модель распределения памяти для того или иного типа данных. Опять же в зависимости от размера распределяемой области оптимальны различные модели организации пометок занято/свободно под капотом менеджера кучи.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь 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. На борту пять. . .	Камера 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. Пошагово создадим проект для загрузки изображения. . .