Сборщик мусора

@_stanislav · Регистрация: 16.08.2014

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

Наткнулся на такие строки и прошу пояснить, что значит.

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

In many languages, resource management is primarily delegated to a garbage collector. C++
also offers a garbage collection interface so that you can plug in a garbage collector

На чем основывается этот интерфейс? И как его подключить. (это про сторонние библиотеки что ли?)

@_stanislav · 02.12.2019, 19:04 **[ТС]**

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

В стандарте есть про GC?

вроде как в С++11 добавили вот цитата Страуструпа с его сайта:

Garbage collection (automatic recycling of unreferenced regions of memory) is optional in C++; that is, a garbage collector is not a compulsory part of an implementation. However, C++11 provides a definition of what a GC can do if one is used and an ABI (Application Binary Interface) to help control its actions.

http://www.stroustrup.com/C++11FAQ.html#gc-abi

а вот цитата и его книги, на всякий случай, если первую страницу темы пропустил:
Сборщик мусора

Добавлено через 59 секунд
документально в стандарте не искал, просто лень мне его читать.

IGPIGP · 02.12.2019, 19:09

Это понимаешь

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

a garbage collector is not a compulsory part of an implementation

?
А это:

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

However, C++11 provides a definition of what a GC can do if one is used and an ABI (Application Binary Interface) to help control its actions.

?
То есть, вроде как сформулированы требования, но нет компиляторов которые это делают. Доступных по крайней мере. Можно создать объектный мир типа шарпа или кьюта и тоже обеспечить автоматику... Можно библиотекой реализовать указатели и их инициализацию.
Можно, наконец, и компилятор заставить это делать ключами, но куча кода не будет компилироваться без кучи гемора. Последний вариант - это процесс ради процесса как говорил поручик Ржевский. То есть, милое дело, для ценителей.

@_stanislav · 02.12.2019, 19:26 **[ТС]**

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

В стандарте есть про GC?

нашел косвенное упоминание:

Storage allocated directly with these functions is implicitly declared reachable (see 6.6.4.4.3) on
allocation, ceases to be declared reachable on deallocation, and need not cease to be declared reachable
as the result of an undeclare_reachable() call. [Note: This allows existing C libraries to remain
unaﬀected by restrictions on pointers that are not safely derived, at the expense of providing far fewer
garbage collection and leak detection options for malloc()-allocated objects. It also allows malloc()
to be implemented with a separate allocation arena, bypassing the normal declare_reachable()
implementation. The above functions should never intentionally be used as a replacement for declare_-
reachable(), and newly written code is strongly encouraged to treat memory allocated with these
functions as though it were allocated with operator new. — end note]

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

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

я думаю ты правильно понял работу стандартного GC

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

@PreZident4442 · 02.12.2019, 19:34

Откуда эти строки?

IGPIGP · 02.12.2019, 19:59

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

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

От Бога, имеешь ввиду?

@_stanislav · 02.12.2019, 20:06 **[ТС]**

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

От Бога, имеешь ввиду

короче ты меня понял, можешь формализовать дальше и больше, плюс я получил ответ на свой вопрос еще в посте https://www.cyberforum.ru/post14050756.html.
Тебя я то же понял кстати, спасибо.

Добавлено через 1 минуту
чуть не так выразился и началось

Добавлено через 1 минуту
при тебе слово стандартный в контексте C++ вообще нельзя говорить по ходу.

IGPIGP · 02.12.2019, 20:12

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

короче ты меня понял, можешь формализовать дальше и больше

Я начинал с С++ Cli, это диалект со сборкой мусора. То есть, видел и конкретное воплощение. Для себя написал пару наивных реализаций для GC и вполне рабочих. Там много чего не было. Кастов указателей например. Но допускались присваивания обычных указателей GC-шным. При чём тут формализм, как таковой? Я просто, как-то потрогал тему за вымя. И это пока является источником уверенности в том, что если нативный код из плюсов выкурят, то начнётся отток программеров в С.

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

спасибо.

Удачи.

@_stanislav · 02.12.2019, 20:15 **[ТС]**

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

то начнётся отток программеров в С

я первый дам деру

@Geek Geekson · 13.12.2022, 17:19

Немного общих размышлений. Зачем вообще прибегают к ручному управлению памятью (new/delete)? Чаще всего чтобы просто выделить её из кучи (а не из стека). Потому что стек маленький. При этом оборачивают голый поинтер в смарт, чтобы он вёл себя как объект с локальной областью видимости (и авто продолжительностью жизни). Так почему же не добавить в язык способ выделения объектов сразу в куче, с автоматической продолжительностью жизни?

Причём многие стандартные классы и контейнеры (тот же vector например) уже имеют такое поведение и проблем с ними вроде особо и нет.

Если где-то ошибаюсь, поправьте.

@DrOffset · 13.12.2022, 17:27

Geek Geekson, динамичекий объект с временем жизни, ограниченным локальным скоупом - это очень частный случай, гораздо чаще нужно передавать куда-то владение. Т.е. условный scoped_ptr (то, о чем говорите вы) и тот же unique_ptr - это разные вещи, и последний нужен гораздо чаще.
С++ вообще в основе своей многое переложил на библиотеки, by design, так сказать. Поэтому чего удивляться, если частная утилитарная задача не решается в core language, т.к. успешно решается библиотечным кодом.

Так же не стоит забывать, что само по себе понятие "куча" очень размыто, потому что язык позволяет перегружать операторы new\delete.

@Geek Geekson · 13.12.2022, 17:48

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

Так же не стоит забывать, что само по себе понятие "куча" очень размыто, потому что язык позволяет перегружать операторы new\delete.

Тут не понял. Стек и куча вроде обеспечиваются самой ОС, и от того что мы в своей программе для каких-то классов придали другой смысл оператору new, как это повлияет на стек и кучу?

@DrOffset · 13.12.2022, 18:13

Сообщение от Geek Geekson

Стек и куча вроде обеспечиваются самой ОС, и от того что мы в своей программе для каких-то классов придали другой смысл оператору new, как это повлияет на стек и кучу?

А при чем тут ОС?
Мы же говорим про объекты в С++ программе. Точнее вы говорите:

Сообщение от Geek Geekson

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

Добавлено через 10 минут
Geek Geekson, С++ не регламентирует как будет устроена куча и как будет устроен стек. И правила в нем не привязаны никак к тому, каким образом это реализует ОС (если она вообще есть), и каким образом это будет реализовывать runtime С++.
Вместо этого используется понятие storage duration; вот от него и надо отталкиваться в обсуждениях, которые затрагивают сам язык.

Так что выше вы фактически предложили вот что: "пусть объекты с dynamic storage duration будут иметь встроенный в язык механизм контролирующий их время жизни в пределах заданного scope". Сама по себе идея так их контролировать в принципе неплоха и прекрасно реализуется библиотечными средствами (это уже сказал).

@Geek Geekson · 13.12.2022, 18:13

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

А при чем тут ОС?
Мы же говорим про объекты в С++ программе.

Ну как же, когда программа запрашивает память из кучи - ОС (если она есть) решает, предоставить её или нет, и по какому адресу. И размер стека по умолчанию задаётся ОС. Если конечно она есть.

@DrOffset · 13.12.2022, 18:36

Сообщение от Geek Geekson

Ну как же, когда программа запрашивает память из кучи - ОС (если она есть) решает, предоставить её или нет, и по какому адресу.

Между ОС и программой есть runtime c++, менеджер памяти которого обычно и предоставляет реализацию "кучи", которую вы используете. Это все конечно непосредственно к языку отношения не имеет, но раз уж вам так хочется поговорить про реализацию, то давайте.
Так вот, из-за этого всякие решения о предоставлении по вашему запросу памяти принимает именно этот менеджер памяти внутри рантайма, а не ОС напрямую.
Т.к. рантайм С++ - при работе программы находится в том же адресном пространстве, что и весь остальной код, то с этой точки зрения абсолютно параллельно каким именно образом будет выделяться память в операторе new (главное, чтобы соблюдались базовые контракты): способом по умолчанию, который предоставляет runtime C++, вашим собственным способом (который даже может в принципе задействовать функции ОС напрямую) или вообще используя свою собственную адресацию с хранением данных в файле вместо памяти (за примером в boost::interprocess). Именно поэтому С++ никакого конкретного понятия "куча" не вводит.

@Renji · 13.12.2022, 18:37

Сообщение от Geek Geekson

Потому что стек маленький.

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

Сообщение от Geek Geekson

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

Вы пытаетесь придумать std::vector. Пожалуйста, автоматическая продолжительность жизни, но "тяжелые" данные вынесены в кучу.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 13. Питон модель трехзонного мицелия, пока что в основном арбускулярного anaschu 28.06.2026 ## Разработка агентной модели микоризной сукцессии: от выявления артефактов к созданию комплексной системы ### Аннотация Представлено исследование по разработке агентной модели микоризной. . .	сукцессия 12. краткий список проверок модели перед запуском. anaschu 27.06.2026 Скрытые отказы в моделях систем динамики (SD-models) экологических систем: два случая из практики Контекст Разбирался прототип модели систем динамики (SD-модели) микоризной сукцессии: пять. . .	Сукцессия 11. Проверка орудий перед войной: разработка через тестирование anaschu 27.06.2026 Как не дать модели соврать самой себе: проверки для симуляции микоризной сукцессии Введение Когда вы строите математическую модель живой системы — грибов, растений, почвы — главная опасность. . .	10 сукцессия. Питон код войны грибов и растений anaschu 27.06.2026 import numpy as np class PlantAgent: def __init__(self, name, strategy, initial_biomass): self. name = name self. strategy = strategy # "greedy" (широколиственные) или. . .
сукцессия 9. Математика подлости: как растения предали грибных друзей anaschu 27.06.2026 Статья 2. Глобальная фосфорная война: эволюционно-экономические механизмы распределения биомов Земли Введение: Экологический рынок как игра с нулевой суммой Традиционная экология долгое время. . .	сукцессия 8. Как я спорил с ИИ, которые - агенты растений и ненавистники грибов! anaschu 27.06.2026 Статья 1. Хроники грибного восстания: как Сократов диалог разрушил академические догмы ИИ Введение: Синдром «цифрового учебника» Современные большие языковые модели (LLM) обладают колоссальным. . .	Главный вопрос моделирования сукцессии anaschu 27.06.2026 главный вопрос. Если эктомикориза лучше добывает недоступный фосфор. И ее масса максимальна из всех. А широколиственный лес тоже имеет самую крутую биомассу. То почему не возникло их симбиоза? Это. . .	сукцессия 6. Питон реализация энилоджиковской модели, картинка про Центральную часть будущей модели anaschu 26.06.2026 Етить. ИИ мне на основе моего старого файла R создал вот эту вот хмерь на пайтоне. Это уже новая модель, модель сукцессии грибной. потоки фосфора, азота. Углерода. 5 видов организмов. Я даже. . .

@_stanislav "C with Classes" 2022 / 1404 / 523 Регистрация: 16.08.2014 Сообщений: 5,885 Записей в блоге: 1

	Сборщик мусора 01.12.2019, 19:38. Показов 10327. Ответов 54 Метки нет (Все метки) Наткнулся на такие строки и прошу пояснить, что значит. Во многих языках управление ресурсами в основном делегируется сбор щику мусора. С++ также предлагает интерфейс сборки мусора, так что вы можете подключить сборщик мусора. In many languages, resource management is primarily delegated to a garbage collector. C++ also offers a garbage collection interface so that you can plug in a garbage collector На чем основывается этот интерфейс? И как его подключить. (это про сторонние библиотеки что ли?) 0

@PreZident4442 0 / 0 / 0 Регистрация: 17.06.2018 Сообщений: 68
	02.12.2019, 19:34
	Откуда эти строки? 0

@Geek Geekson 3 / 3 / 0 Регистрация: 12.07.2022 Сообщений: 216
	13.12.2022, 17:19
	Немного общих размышлений. Зачем вообще прибегают к ручному управлению памятью (new/delete)? Чаще всего чтобы просто выделить её из кучи (а не из стека). Потому что стек маленький. При этом оборачивают голый поинтер в смарт, чтобы он вёл себя как объект с локальной областью видимости (и авто продолжительностью жизни). Так почему же не добавить в язык способ выделения объектов сразу в куче, с автоматической продолжительностью жизни? Причём многие стандартные классы и контейнеры (тот же vector например) уже имеют такое поведение и проблем с ними вроде особо и нет. Если где-то ошибаюсь, поправьте. 0

@DrOffset 19501 / 10106 / 2461 Регистрация: 30.01.2014 Сообщений: 17,825
	13.12.2022, 17:27
	Geek Geekson, динамичекий объект с временем жизни, ограниченным локальным скоупом - это очень частный случай, гораздо чаще нужно передавать куда-то владение. Т.е. условный `scoped_ptr` (то, о чем говорите вы) и тот же `unique_ptr` - это разные вещи, и последний нужен гораздо чаще. С++ вообще в основе своей многое переложил на библиотеки, by design, так сказать. Поэтому чего удивляться, если частная утилитарная задача не решается в core language, т.к. успешно решается библиотечным кодом. Так же не стоит забывать, что само по себе понятие "куча" очень размыто, потому что язык позволяет перегружать операторы new\delete. 0