LINUX.ORG.RU

Ответ на: комментарий от KblCb

В плюсах нет сборщика мусора.

что, C++ уже по твоему лишился Тьюринг-полноты, и там нельзя чего-то написать? Или ты просто не осилил? Ну дык возьми готовый GC.

emulek
()
Ответ на: комментарий от next_time

Он очень условно пригоден для использования в плюсах. Все попытки сделать в плюсах mark and sweep GC как правило упираются в невозможность эффективно найти корневые объекты от которых начнётся поиск доступных объектов.

KblCb ★★★★★
()

// тред не читай @ сразу отвечай

да, такие библиотеки есть. например, Wt 1 2 3 оффсайт yahoo.eu

видео ОРМа

ещё есть С++СMS, например.

зачем это нужно — ну ХЗ. кто-то вот написал.

anonymous
()
Ответ на: комментарий от KblCb

плюсы вообще плохо приспоблены для сборки мусора сборщиком (а не фанатами треш-технологий). например, только консервативный сборщик мусора — что-то более современное: поколенческий, такой как ephemeral gc из лиспа, или что-то ещё с полупространствами — всё это недоступно в С++ by design.

хотя в Oberon-2 Component Pascal, например в BlackBox Component Pascal и mark & sweep неплохо работает (там GC написан на самом паскале. ещё в Nimrod есть GC написанный на самом Nimrod, и для ML что-то такое было).

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

anonymous
()
Ответ на: комментарий от Anon

А насчет плюсов ты прав: я их не знаю и знать не хочу. Когда-то давно учил, даже что-то начинал кодить. Но понял, что ни одной фичи C++ я использовать в своих велосипедах не смогу, т.к. уж больно они простые. А раз не нужно полноценное ООП, зачем тогда эту дрянь непонятную тянуть?

нет, ты чо. нужно настоятельно обмазаться бустом и генерить HTML шаблонами, пускай по паре часов конпелирует. зачем нужен этот троллейбус из буханки? а because we can, нуачо.

мы не боимся трудностей. мы — китайские комсомольцы, конпелируем на С++ !!!

anonymous
()
Ответ на: комментарий от emulek

дык никто не заставляет. Просто писать много, и есть существенный риск забыть free и/или вызвать неправильный malloc. Со своей системой управления памятью такой риск ниже. Вот в php ты в принципе буфер не переполнишь, ибо резиновый. В C++ ты можешь сделать точно такой же (фактически, в php уже и сделано так, на C++).

ортогонально. переполнение буфера при неаккуратности может вылезти в каком-то стрёмном месте на границе (как например в COM с API BSTRING, где были костыльные функции где нужно было учитывать кто кому выделяет память, кто освобождает, клиент или сервер, учитывать семантику владения, копирования перемещения, и прочая).

anonymous
()
Ответ на: комментарий от KblCb

Все попытки сделать в плюсах mark and sweep GC как правило упираются в невозможность эффективно найти корневые объекты от которых начнётся поиск доступных объектов.

а никто не заставляет делать GC над глупыми указателями. Можно делать и над умными, как в других ЯП.

Я вообще таких хейтеров как вы не понимаю: если в ЯП есть что-то, то разве обязательно это что-то юзать ВСЕГДА?

Да, у обычного указателя ничего нет, кроме адреса и размера. Причём и то и то — платформозависимо. Ну дык юзайте умные указатели, с бледжеком и шлюхами, кто против?

emulek
()
Ответ на: комментарий от anonymous

что-то более современное: поколенческий, такой как ephemeral gc из лиспа, или что-то ещё с полупространствами — всё это недоступно в С++ by design.

бред. By design в C/C++ даже helloworld невозможно написать, если уж на то пошло.

emulek
()
Ответ на: комментарий от anonymous

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

кто-то заставляет? Я тоже не люблю boost.

emulek
()
Ответ на: комментарий от emulek

а никто не заставляет делать GC над глупыми указателями. Можно делать и над умными, как в других ЯП.

Дело не в указателях, а в их расположение. Как ты определишь какие указатели (даже если они очень умные) в момент сборки мусора находятся на стеке?

KblCb ★★★★★
()
Ответ на: комментарий от KblCb

А теперь задайте тот же самый вопрос, но на этот раз сформулируйте его грамотно. В правильно заданном вопросе, как известно, половина ответа.

next_time ★★★★★
() автор топика
Ответ на: комментарий от KblCb

Как ты определишь какие указатели (даже если они очень умные) в момент сборки мусора находятся на стеке?

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

emulek
()
Ответ на: комментарий от emulek

это не правильный ответ, правильный ответ гораздо проще

next_time ★★★★★
() автор топика
Ответ на: комментарий от dzidzitop

Дааа??? И таки шо это такое:

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
???

Anon
()
Ответ на: комментарий от dzidzitop

А мне-то что? Оно лежит в libc? Лежит. Все, кыш!

Anon
()
Ответ на: комментарий от templarrr

Затем, что ruby и python ещё нужно выучить. Причём, помимо синтаксиса ещё стандартные библиотеки на них. Т.е., это занимает определённое время. При этом, как человек поверхностно знакомый с несколькими ЯП (помимо хорошего знания плюсов), в т.ч. и с ruby и c python-ом и с лиспом и чуток с функциональщиной, скажу что C++ и C# — это самые развитые ЯП, по количеству фич на уровне синтаксиса опережающие все остальные языки. Т.е. если сравнивать плюсы с руби/питоном, недостаток последних не только в том, что в них нет толком новых ключевых возможностей, ради которых был бы смысл учить новый язык, но у них даже нет толком синтаксического сахара, осутствующего в плюсах. При этом, некоторые фичи плюсов by design отсутствуют — например, статическая типизация.

next_time ★★★★★
() автор топика
Ответ на: комментарий от KblCb

То есть ВСЕ ссылки — корневые и не нуждаются в сборке?

нет. Просто ссылки делаются НЕ ТАК, как в C++. А с помощью operator=(). Т.е. если ты делаешь

Array X();
Array Y();
Y = X;
то у тебя создаётся ссылка на X в Y, при этом сам Y становится мусором. И со временем уничтожается GC (возможно не сразу).

emulek
()
Ответ на: комментарий от templarrr

А зачем заменять php именно крестами, когда есть ruby и python?

зачем менять хрен мёдом, если есть редька?

emulek
()
Ответ на: комментарий от next_time

При этом, как человек поверхностно знакомый с несколькими ЯП (помимо хорошего знания плюсов), в т.ч. и с ruby и c python-ом и с лиспом и чуток с функциональщиной, скажу что C++ и C# — это самые развитые ЯП, по количеству фич на уровне синтаксиса опережающие все остальные языки.

я один вижу в твоём высказывании ВП?

Смотри, я знаю русский язык (он для меня родной), и поверхностно английский. Вот если меня по-англ. послать куда-то, то я пойму, куда надо идти, но не пойму, шутят надомной, просто объяснили куда идти, или грубо выругались. Ибо язык знаю поверхностно. Ты уверен в том, что на английском «нет нужных фич» для всего этого?

emulek
()
Ответ на: комментарий от emulek

Хорошо. Становится ли мусором Y в этом случае?

Array X();
Array Y();
Array Z();
Z = Y;
Y = X;

И каким образом ты собираешься проверять нужен ли объект или уже нет?

KblCb ★★★★★
()
Ответ на: комментарий от KblCb

Хорошо. Становится ли мусором Y в этом случае?

Array X();
Array Y();
Array Z();
Z = Y;
Y = X;

нет конечно. Ибо тут Y нужен ещё и Z.

И каким образом ты собираешься проверять нужен ли объект или уже нет?

первый operator= запомнит, что Y нужен объекту Z. Потому GC не тронет Y, если Z ещё жив(и значение его не менялось).

emulek
()
Ответ на: комментарий от emulek

Прошу прощения за вопрос, а нахрена тут GC? Вот как раз в этой задаче он совсем не сдался.. Тут нужен простой пул, который связан с запросом. В рамках обработки запроса, всю память выделяем в этом пуле. Запрос обработали, весь пул освободили. Именно так сделано в nginx.

vromanov ★★
()
Ответ на: комментарий от vromanov

Прошу прощения за вопрос, а нахрена тут GC? Вот как раз в этой задаче он совсем не сдался.. Тут нужен простой пул

ну это только пять строк. IRL может быть 55 555 строк, и без GC в принципе будет не запомнить, что там произошло с Y.

А с простым пулом конечно проще, но часто он требует Over9000Гб памяти. А их почему-то никто не даёт...

emulek
()
Ответ на: комментарий от emulek

не понял, почему пул требует много памяти? Можно сделать пул не простым, т.е. на самом деле цепочку блоков, а не один блок большой длинны. На мой взгляд как раз решение с пулом выдает меньшие затраты по памяти, чем использование gc. Т.к. в случе с GC все указатели перестают быть просто указателями

vromanov ★★
()
Ответ на: комментарий от KblCb
Array Y = { X };
Array X = { Y };

ну вот здесь, если {} это инициализация массива подразумевается, то должно быть исключение/ошибка в конструкторе. Циклическая ссылка. Она не имеет смысла, как и деление на ноль. Это конечно от задачи зависит, но обычно делают именно так.

emulek
()
Ответ на: комментарий от emulek

Две структры, котрые содержат внутри указатели на другую структуру. Или двухсвязный список. Или дерево с указателями папа-ребенок

vromanov ★★
()
Ответ на: комментарий от vromanov

не понял, почему пул требует много памяти?

потому-что пул в 1Гб требует 1Гб. А вот если не лезет 501й мегабайт, то можно запустить GC. Потому пул занимает больше.

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

ИМХО это один из вариантов GC. Основной недостаток — ты быстро получишь Over9000 заполненных наполовину блоков. И что с ними делать?

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

зависит от стратегии выделения памяти. Ну т.е. от задачи. В общем случае — хрен его знает.

emulek
()
Ответ на: комментарий от vromanov

Array Y = { X };Array X = { Y };

с указателями папа-ребенок

ты белены объелся: тут написано, что твой сын является твоим отцом.

emulek
()
Ответ на: комментарий от emulek

Да нет. Вполне нормальная ситуация: у всех детей есть ссылка на родителя, а у родителей на детей. Это довольно распространённая ситуация например в библиотеках виджетов и чёрт знает ещё где. И довольно известный факт, что счётчики ссылок не могут решить такую задачу вообще (если не вводить слабые ссылки). Под сборщиком мусора я всё же подразумевал что-то более разумное.

KblCb ★★★★★
()
Ответ на: комментарий от KblCb

Да нет. Вполне нормальная ситуация: у всех детей есть ссылка на родителя, а у родителей на детей.

это совсем другое.

Это довольно распространённая ситуация например в библиотеках виджетов и чёрт знает ещё где

виджет не может включать в себя компонент, включающий сам этот виджет. Это не имеет смысла.

И довольно известный факт, что счётчики ссылок не могут решить такую задачу вообще

при чём тут вообще счётчик ссылок? Света с Климом сошлась в любовном экстазе?

emulek
()
Ответ на: комментарий от vromanov

На надо вводить пул 1Гб. Никто так не делает

ты писал «простой пул». Что ты имеешь ввиду, говоря эти слова? Я так понял — просто кусок памяти скажем в гиг.

emulek
()
Ответ на: комментарий от emulek

я ваще охреневаю от жабообезьян: У них всего два GC

  • кривой косой GC на глупых указателях и со счётчиком ссылок в C++.
  • белая добрая дружбомагия в java. Никто не знает, как она работает, но работает она ИДЕАЛЬНО.
emulek
()
Ответ на: комментарий от emulek

это совсем другое.

Это ровно тоже самое. Или тебя смутил синтаксис инициализации из C++11?

виджет не может включать в себя компонент, включающий сам этот виджет. Это не имеет смысла.

Не компонент, а ссылку на компонент. Так сделано примерно везде.

при чём тут вообще счётчик ссылок?

Алгоритм определение мусора и не мусора в студию.

KblCb ★★★★★
()
Ответ на: комментарий от KblCb

Это ровно тоже самое. Или тебя смутил синтаксис инициализации из C++11?

это HEX.

Не компонент, а ссылку на компонент. Так сделано примерно везде.

тебе никогда не понять, чем отличается «передача объекта по ссылке» от «передачи ссылки на объект», да? Тогда смирись с тем, что C++ это не твоё. А я не умею рисовать, и не стыжусь этого. И ты не стыдись. Здесь нет ничего постыдного.

Алгоритм определение мусора и не мусора в студию.

ну разве он не очевиден? Если ты испортил объект, то его старое значение == мусор. Вот в этом коде

Y = X
объект Y портится, и становится мусором

а здесь

Z = Y
Y = X
объект Y НЕ портится. Потому-что он сохранён в Z.

А ссылки, и тем более их счётчики, это всего-лишь одна из реализаций данной идеи.

«Лучшего» способа нет, и быть не может. Каждый способ где-то хорош, а где-то плох. Счётчики ссылок — не исключение.

emulek
()
Ответ на: комментарий от emulek

чем отличается «передача объекта по ссылке» от «передачи ссылки на объект»

Очень любопытно. И в чём отличие?

ну разве он не очевиден?

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

KblCb ★★★★★
()
Ответ на: комментарий от KblCb

придётся разжевать.

Дело не в указателях, а в их расположение. Как ты определишь какие указатели (даже если они очень умные) в момент сборки мусора находятся на стеке?

Тот же вопрос, но более грамотно звучит так: «как ты определишь, какие указатели в момент сборки мусора указывают на память, выделенную с помощью оператора new, а какие - нет?». Напомню, что освобождаем мы не указатели как таковые, а память, на которую они указывают, поэтому, нам достаточно знать, по каким адресам находится память, выделенная с помощью оператора new, мы же сами зряче использовали этот оператор. А оператор этот может быть перегружен и выполнять любые действия, какие нам заблагорассудится, соответственно, ответ на ваш вопрос: мы это знаем практически by design.

next_time ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.