А как у вас референс каунт вообще к GC относится?

это ж разные вещи, в питоне, например, эти два механизма освобождения памяти работают параллельно

Референс каунтер в пайтоне - это часть реализации gc. С shared_ptr это никак не связано.

Это не часть реализации GC, это два разных механизма

В пайтоновском gc есть и подсчёт ссылок, и m&s.

Нет, опять же. Рефкаунты вообще никакого отношения к gc не имеют. GC ты можешь отключить через gc.disable, рефкаунты - нет

Хмм, да, ты прав, рефкаунтер не отключается при отключении gc. Но мой поинт в том, что это часть механизма gc, которая не имеет отношения к умным указателям в крестах.

Согласен, да, к ним нет доступа у простых смертных вне C API питона

но подсчёт ссылок — часть механизма сборки мусора

Нет

дат

Ну, значит, C — язык с "механизмом сборки мусора", или хотя бы его "частью"

Возможно, речь не про чистый C, а про C++ с его std::shared_ptr. То да, частично сборка мусора в C++11 появилась

контекст не читаем? https://t.me/vimers/112969 "целые языки со сборщиками мусора, которые сделаны на подсчете ссылок (Перл, Питон), и никто же не утверждает, что это языки без сборки мусора"

Ну это же вы недостаточно контекст прочитали:)

Еще раз - в питоне есть и GC и refcnt, одно не является другим

с чего бы это не является? refcount - всего лишь один из способов имплементации GC

то, за что отвечает питоновский модуль gc — это аж поколенческий сборщик мусора

нет, рефкаунт - это имплементация смарт поинтеров, с автоматическим dealloc по достижению 0, GC - это механизм обнаружения unreachable объектов при циклических референсах, которые RC не разрулит из-за своей простоты

каких еще смарт-поинтеров? перечитывай с места "есть целые языки ..."

Взять ту же Википедию. Там описан стратегия подсчёта ссылок алгоритма сборки мусора. Она оттуда ссылается на Майкрософт.

Вы путаете причину и следствие Бывают части гц, основанным на подсчете ссылок, но не любой код, который считает количество ссылок на объект — сборщик мусора

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

Ну тогда это бесполезная классификация:)

malloc и free тоже используется вместо ручного управления памятью. Вообще не сути понимаю претензий. То, что стандартная библиотека сложно отключается? Не сложнее чем в С. То, что много кода юзает стандартную библиотеку? В С тоже много кода юзает стандартную библиотеку

> malloc и free тоже используется вместо ручного управления памятью лолшто? они и есть ручное управление памятью

Нет, конечно, "ручное" управление памяти — это mmap/sbrk или аналоги, аллокаторы же сложнее кода значительной части программ, что их используют Там и подсчет ссылок, и deferred reclamation, и так далее

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

Не до конца ручное таки

пфф, mmap/sbrk - это всего лишь детали реализации malloc/free с точки зрения прикладника, саму суть того, что это ручное управление - оно не меняет.

немножко беременна?

Нет, mmap уж точно не деталь реализации malloc/free

именно деталь, потому что на другой ОС (например винде) malloc/free будет работать не через mmap

Что? Да, оно в итоге дергает mmap/munmap

оно или ручное, или не ручное

Define не ручное

Только если рассматривать в контексте реализации аллокатора, интерфейс-то сильно шире

И define ручное, да

ну сравни Си с JS, Перлом или Питоном, сразу увидишь

Речь же про Rc/Arc вроде? Они "ручное", или нет?

ручное - это когда руками зовешь malloc/free

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

> добавлена сбоку будучи написанной на самом ЯП > они не часть языка вот это и есть пиздёж, подпадающий под "сообщество фанатиков"

в C++ тогда тоже есть сборщик мусора, потому что там такой же std::shared_ptr в стдлибе

Ну вот я руками дропаю рц https://doc.rust-lang.org/src/alloc/rc.rs.html#1445-1461

это уже обсуждали, читай выше