Он очень условно пригоден для использования в плюсах. Все попытки сделать в плюсах mark and sweep GC как правило упираются в невозможность эффективно найти корневые объекты от которых начнётся поиск доступных объектов.
плюсы вообще плохо приспоблены для сборки мусора сборщиком (а не фанатами треш-технологий). например, только консервативный сборщик мусора — что-то более современное: поколенческий, такой как ephemeral gc из лиспа, или что-то ещё с полупространствами — всё это недоступно в С++ by design.
хотя в Oberon-2 Component Pascal, например в BlackBox Component Pascal и mark & sweep неплохо работает (там GC написан на самом паскале. ещё в Nimrod есть GC написанный на самом Nimrod, и для ML что-то такое было).
то есть, можно таки GC сделать не абы как попало, в нормальных языках. если захотеть и язык не кресты.
А насчет плюсов ты прав: я их не знаю и знать не хочу. Когда-то давно учил, даже что-то начинал кодить. Но понял, что ни одной фичи C++ я использовать в своих велосипедах не смогу, т.к. уж больно они простые. А раз не нужно полноценное ООП, зачем тогда эту дрянь непонятную тянуть?
нет, ты чо. нужно настоятельно обмазаться бустом и генерить HTML шаблонами, пускай по паре часов конпелирует. зачем нужен этот троллейбус из буханки? а because we can, нуачо.
мы не боимся трудностей. мы — китайские комсомольцы, конпелируем на С++ !!!
дык никто не заставляет. Просто писать много, и есть существенный риск забыть free и/или вызвать неправильный malloc. Со своей системой управления памятью такой риск ниже. Вот в php ты в принципе буфер не переполнишь, ибо резиновый. В C++ ты можешь сделать точно такой же (фактически, в php уже и сделано так, на C++).
ортогонально. переполнение буфера при неаккуратности может вылезти в каком-то стрёмном месте на границе (как например в COM с API BSTRING, где были костыльные функции где нужно было учитывать кто кому выделяет память, кто освобождает, клиент или сервер, учитывать семантику владения, копирования перемещения, и прочая).
Все попытки сделать в плюсах mark and sweep GC как правило упираются в невозможность эффективно найти корневые объекты от которых начнётся поиск доступных объектов.
а никто не заставляет делать GC над глупыми указателями. Можно делать и над умными, как в других ЯП.
Я вообще таких хейтеров как вы не понимаю: если в ЯП есть что-то, то разве обязательно это что-то юзать ВСЕГДА?
Да, у обычного указателя ничего нет, кроме адреса и размера. Причём и то и то — платформозависимо. Ну дык юзайте умные указатели, с бледжеком и шлюхами, кто против?
Как ты определишь какие указатели (даже если они очень умные) в момент сборки мусора находятся на стеке?
например ВСЕ. (конечно внутренние структуры могут выделятся по new и хранится в глупых указателях. Но это внутренняя реализация). Ну а что-бы ява-обезьяны не пытались сделать new, его можно и перезагрузить.
nm /lib/libc.so.6 | grep socket
0000000000114bf0 t __get_socket
00000000000ea080 t __GI_socket
00000000000ea080 t __GI___socket
00000000000ea0b0 t __GI_socketpair
00000000000ea0b0 t __GI___socketpair
0000000000114140 t key_call_socket
000000000011c300 t __nscd_open_socket
000000000011b770 t open_socket
00000000000ea080 W socket
00000000000ea080 t __socket
00000000000ea0b0 W socketpair
00000000000ea0b0 t __socketpair
000000000011b660 t wait_on_socket
Затем, что ruby и python ещё нужно выучить. Причём, помимо синтаксиса ещё стандартные библиотеки на них. Т.е., это занимает определённое время. При этом, как человек поверхностно знакомый с несколькими ЯП (помимо хорошего знания плюсов), в т.ч. и с ruby и c python-ом и с лиспом и чуток с функциональщиной, скажу что C++ и C# — это самые развитые ЯП, по количеству фич на уровне синтаксиса опережающие все остальные языки. Т.е. если сравнивать плюсы с руби/питоном, недостаток последних не только в том, что в них нет толком новых ключевых возможностей, ради которых был бы смысл учить новый язык, но у них даже нет толком синтаксического сахара, осутствующего в плюсах. При этом, некоторые фичи плюсов by design отсутствуют — например, статическая типизация.
При этом, как человек поверхностно знакомый с несколькими ЯП (помимо хорошего знания плюсов), в т.ч. и с ruby и c python-ом и с лиспом и чуток с функциональщиной, скажу что C++ и C# — это самые развитые ЯП, по количеству фич на уровне синтаксиса опережающие все остальные языки.
я один вижу в твоём высказывании ВП?
Смотри, я знаю русский язык (он для меня родной), и поверхностно английский. Вот если меня по-англ. послать куда-то, то я пойму, куда надо идти, но не пойму, шутят надомной, просто объяснили куда идти, или грубо выругались. Ибо язык знаю поверхностно. Ты уверен в том, что на английском «нет нужных фич» для всего этого?
Прошу прощения за вопрос, а нахрена тут GC? Вот как раз в этой задаче он совсем не сдался.. Тут нужен простой пул, который связан с запросом. В рамках обработки запроса, всю память выделяем в этом пуле. Запрос обработали, весь пул освободили.
Именно так сделано в nginx.
не понял, почему пул требует много памяти? Можно сделать пул не простым, т.е. на самом деле цепочку блоков, а не один блок большой длинны. На мой взгляд как раз решение с пулом выдает меньшие затраты по памяти, чем использование gc. Т.к. в случе с GC все указатели перестают быть просто указателями
ну вот здесь, если {} это инициализация массива подразумевается, то должно быть исключение/ошибка в конструкторе. Циклическая ссылка. Она не имеет смысла, как и деление на ноль. Это конечно от задачи зависит, но обычно делают именно так.
Да нет. Вполне нормальная ситуация: у всех детей есть ссылка на родителя, а у родителей на детей. Это довольно распространённая ситуация например в библиотеках виджетов и чёрт знает ещё где. И довольно известный факт, что счётчики ссылок не могут решить такую задачу вообще (если не вводить слабые ссылки). Под сборщиком мусора я всё же подразумевал что-то более разумное.
Это ровно тоже самое. Или тебя смутил синтаксис инициализации из C++11?
это HEX.
Не компонент, а ссылку на компонент. Так сделано примерно везде.
тебе никогда не понять, чем отличается «передача объекта по ссылке» от «передачи ссылки на объект», да? Тогда смирись с тем, что C++ это не твоё. А я не умею рисовать, и не стыжусь этого. И ты не стыдись. Здесь нет ничего постыдного.
Алгоритм определение мусора и не мусора в студию.
ну разве он не очевиден? Если ты испортил объект, то его старое значение == мусор. Вот в этом коде
Y = X
объект Y портится, и становится мусором
а здесь
Z = Y
Y = X
объект Y НЕ портится. Потому-что он сохранён в Z.
А ссылки, и тем более их счётчики, это всего-лишь одна из реализаций данной идеи.
«Лучшего» способа нет, и быть не может. Каждый способ где-то хорош, а где-то плох. Счётчики ссылок — не исключение.
Дело не в указателях, а в их расположение. Как ты определишь какие указатели (даже если они очень умные) в момент сборки мусора находятся на стеке?
Тот же вопрос, но более грамотно звучит так: «как ты определишь, какие указатели в момент сборки мусора указывают на память, выделенную с помощью оператора new, а какие - нет?». Напомню, что освобождаем мы не указатели как таковые, а память, на которую они указывают, поэтому, нам достаточно знать, по каким адресам находится память, выделенная с помощью оператора new, мы же сами зряче использовали этот оператор. А оператор этот может быть перегружен и выполнять любые действия, какие нам заблагорассудится, соответственно, ответ на ваш вопрос: мы это знаем практически by design.