Сборка мусора на умных указателях

Чисто не там где убирают, а где не мусорят. Сборка мусора для слабаков.

Use Java, Luke

Чисто не там где убирают, а где не мусорят

Надо запомнить данное выражение, хорошо Вы сказали.

интерестное утверждние. пожалуй плюсану.

В питоне все объекты имеют ссылок счётчики. Счётчик с нулём собирается мусорщиком. Это ты имеешь в виду?

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

Это shared_ptr, и с ним связаны известные проблемы. Я предлагаю модный отслеживающий gc.

Чисто не там где убирают, а где не мусорят.

Хрен. Немцы мусорят поболее нашего, но на улицах чисто. Потому что ночью там тщательно убирают.

Я такое делал на старой работе, и оно даже работало.

Сборка мусора для слабаков

А как быть в ситуации когда невозможно предсказать время когда объект должен быть уничтожен?

Сразу видно типичного C++ кодеришку. С++ кодеры - не программисты, гоните их, надсмехайтесь над ними.txt

приведи более конкретный пример.

А как быть в ситуации когда невозможно предсказать время когда объект должен быть уничтожен?

Нормально проектировать? Ну или на крайняк выбирать инструментарий по зубам?! не?

Я прикинул реализацию, и меня немного смущают накладные расходы: три слова на указатель, +1 на объект, и небыстрое создание/удаление указателя. Вот и хотелось посмотреть, нельзя ли сделать лучше.

http://en.wikipedia.org/wiki/Persistent_data_structure, например.

Нормально проектировать? Ну или на крайняк выбирать инструментарий по зубам?! не?

Даже для С++ это не всегда верно. Если данные шапятся между несколькими пользователями этих данных без автоматической сборки мусора получится лапша или своя локальная реализация сборщика. Во всяких ФП и околоФП языках вручную за этим вообще не уследить, по-моему.

три слова на указатель, +1 на объект, и небыстрое создание/удаление указателя.

Э-э-э, это зачем? Для mark-and-sweep?

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

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

Указатели помещаю в двусвязный список, объекты - в односвязный. А как иначе их обходить?

Чисто не там где убирают, а где не мусорят. Сборка мусора для слабаков.

выводы:
0. не выделяй под объекты память вообще
1. не выделяй под объекты память в куче, а только в стеке
2. если выделил в куче - не удаляй

Указатели помещаю в двусвязный список, объекты - в односвязный. А как иначе их обходить?

А, понял. Нет, я делал несколько иначе: для каждого класса статически формировался список его членов-указателей, которые контролируются GC.

Надо правильно проектировать, если проектировщик не способен учесть особенности ЯП и/или правильно выбрать инструментарий, значит он профан...

Слова теоретика.

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

Слова фанатика.

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

А как найти корневые объекты?

Фу, теперь быстро смой весь этот жир!

Чисто не там где убирают, а где не мусорят.

Там где часто убирают тоже чисто.

Сборка мусора для слабаков.

доказательство по аналогии для слабаков.

Слова теоретика.

Ага, конечно, и никак иначе... ещё школо-ло и троло-ло.... и вообще все придурки кроме тебя.

Слова фанатика.

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

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

Смотря что под этим подразумевать.

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

Если это лучший вариант, следует избрать подходящий инструмент. Что бы в квартире сделать дырочку в бетонной стене (картинку повесить или там полочку) я беру в руки перфоратор, а не отбойный моток (да ещё и прикручиваю к нему изолентой и проволокой переходник на sds-plus насадки). Есть годные ЯП со сборщиками мусора, если нужен GC, выбирай инструментарий его имеющий. Будет быстро, качественно, без попоболи, дешево и сердито.

Там где часто убирают тоже чисто.

Только не долго, да ещё за регулярную уборку приходится платить...

доказательство по аналогии для слабаков.

что?

Только не долго, да ещё за регулярную уборку приходится платить...

Об одном ты забыл. Мусор есть всегда. У одних его убирает робот-уборщица, а другие сами со шваброй бегают. Причём вторые зачастую оставляют кучу грязи.

Ага, конечно, и никак иначе... ещё школо-ло и троло-ло.... и вообще все придурки кроме тебя.

Интересная цепочка рассуждений. Продолжай.

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

Хорошо, пользователя-фанатика. Все стреляли себе в ноги, но не многие после этого кичатся остротой своего инструмента.

Есть годные ЯП со сборщиками мусора, если нужен GC, выбирай инструментарий его имеющий. Будет быстро, качественно, без попоболи, дешево и сердито.

Есть годные языки c ГЦ. Но и для С++ есть ГЦ. Часто окажется проще и лучше в плане производительности использовать плюсовый ГЦ, чем пытаться скрещивать систему на С++ с другими языками.

С++ кодеры - не программисты, гоните их, надсмехайтесь над ними.txt

Их и так природа обидела. Нехорошо насмехаться над убогими.

если выделил в куче - не удаляй

В утилитах, задача которых быстро выплюнуть данные и сдохнуть, — самый оптимальный вариант.

Об одном ты забыл. Мусор есть всегда. У одних его убирает робот-уборщица, а другие сами со шваброй бегают. Причём вторые зачастую оставляют кучу грязи.

Если ты динамическую память используешь аккуратно, т.е. не мусоришь. Убирать то и нечего. Вот смотри (вариант прикостыленного GC к крестам) я покушал, тарелку помыл, мусор есть? Нет. Я тарелку легко помыл, она одна мне было не влом. А теперь прикинь, что я мою их только накопив... Приходит время помыть, в раковине ад. Посуды дохрена, к ней всё присохло, отмывается плохо, время на мытьё требуется дофига, мыть в лом, етц. И всё время от первой трапезы до последней в раковине был мусор, налить воду в чайник было затруднительно... беда. А теперь прикинь что у меня есть посудомоечная машина (вариант ЯП с нормальным GC). Я покушал, в машину кинул. Там много раз. Пришло время, положил таблетку (мыло), нажал кнопку. В раковине было чисто (смотреть приятно, чайник наполнить ни чего не мешает), я точно так же не напрягался. Скажешь я не прав?!

Скажешь я не прав?!

Феерическое доказательство «прикостыленности» ГЦ к С++ на тарелочках, я это схороню.

Но и для С++ есть ГЦ

Имеется в виду Boehm GC или что-то другое?

Интересная цепочка рассуждений. Продолжай.

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

Хорошо, пользователя-фанатика.

Аргументов как не было, так и нету...

Все стреляли себе в ноги, но не многие после этого кичатся остротой своего инструмента.

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

Есть годные языки c ГЦ. Но и для С++ есть ГЦ. Часто окажется проще и лучше в плане производительности использовать плюсовый ГЦ, чем пытаться скрещивать систему на С++ с другими языками.

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

Во-во-во, когда нечего по теме сказать начинается приплетение нелепых аналогий. А теперь попробуй выразить свои мысли техническим языком в терминах накладных расходов, задержек и так далее. Потом подумаем кому этот оверхед критичен, а кому нет.

Прибавим к этому человеческий фактор. Не все умеют «мыть посуду».

вариант ЯП с нормальным GC

я точно так же не напрягался

я не понял, ты за gc или против?

Феерическое доказательство «прикостыленности» ГЦ к С++ на тарелочках, я это схороню.

что? это утверждение? запрос? вопрос?

Во-во-во, когда нечего по теме сказать начинается приплетение нелепых аналогий. А теперь попробуй выразить свои мысли техническим языком в терминах накладных расходов, задержек и так далее. Потом подумаем кому этот оверхед критичен, а кому нет.

Аналогии - отличный инструмент, для пояснений, способ показать с какой стороны я смотрю на вопрос... Уж лучше не аргументированных ИМХО.

Прибавим к этому человеческий фактор. Не все умеют «мыть посуду».

Посудомоечная машина умеет. Если у тебя хреновые кодеры исполняют задачу, давай им инструментарий проще. Детям на уроках труда дают пластмасовые ножницы.

я не понял, ты за gc или против?

И да и нет. GC - следует использовать только там, где это уместно. И не стоит его прикручивать сбоку в виде костыля, есть годные готовые решения решения, в которых GC встроен by design.

Аналогии - отличный инструмент

Да брось, тут не домохозяйки. Я же написал выше что у каждого подхода есть свои плюсы и минусы. Когда говорят «gc говно и оно никому не нужно» это слова идиота. Когда говорят «на моих задачах это не работает из-за того-то и того-то» это уже можно назвать дискуссией. А доказательство по аналогии оставь другим.

Уж лучше не аргументированных ИМХО.

не надо спускаться на такой уровень.

я что-то против этого дела.

дело в том, что reference counterы или потоко небезопасны, или весьма больно бьют по шине на армах. это раз. ну и lockед команды неплохо обламывают внутрипроцовую оптимизацию.

дело в том, что у объекта в принципе может быть __три__ типа ссылок: жесткие, которые мы контроллируем потому что они локально в стеке хранятся(1), жесткие, которые хранятся в контейнере(2), и мягкие(3).

для (1) вообще ссылки считать не надо. т.е. создал объект с refcount=0 (как в GTK виджеты) и удалил когда надоело. ибо большинство объектов юзаются в одно рыло! refcount излишен там.

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

чуть только вышел - ссылки добавлять только при помещении в контейнеры. т.е. как только ушел в нелокальную переменную указатель - все, теперь он типа (2).

тип (3) вообще эмулируется с помощью объекта-прослойки размером в 16-32 байта, и применением правила (2) для этого объекта.

ну и счетчик встроенный, вроде intrusive_ptr.

Cocoa-way получается.

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

А как найти корневые объекты?

А какая связь?

Имеется в виду Boehm GC или что-то другое?

Вообще имелось в виду любое не ручное управление памятью и boehm gc в том числе. В студенчестве я и сам велосипедил свой GC just for fun.

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

Аргументов как не было, так и нету...

Так про проектировщиков-недоучек, острые лезвия, тарелочки и слабаков - все это были аргументы?

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

Совсем необязательно куда-то напарываться, чтобы отбросить стереотипы и мыслить шире, в том числе при проектировании. Сборку мусора можно изначально заложить в проект на С++ и не обязательно прикручивать к нему лиспы с хаскелями.

что? это утверждение? запрос? вопрос?

Это утверждение. Я схоронил твои размышления о тарелочках - показательный пример дурных аналогий. Буду детям показывать.

Ты дебил. Твоя мамка - шлюха.

Реализуй интерпретатор простого, нетипизированного лямбда-исчисления. Без GC. Вперед, недоумок, время пошло.

Так про проектировщиков-недоучек, острые лезвия, тарелочки и слабаков - все это были аргументы?

Аргументы и аналогии вещи разные, осиль перенести и сопоставить с сабжем.

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

Где я сказал что обязательно на что-то напарываться, что бы проектировать?!

Сборку мусора можно изначально заложить в проект на С++ и не обязательно прикручивать к нему лиспы с хаскелями.

А теперь роди пруф, где я говорил прикручивать к проекту на крестах что либо?! Давай, давай, давай!!! Я жду!!!

Это утверждение. Я схоронил твои размышления о тарелочках - показательный пример дурных аналогий. Буду детям показывать.

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

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

Я и говорю, что посудомоечная машина (ака GC) классная штука. Даже если причина её приобретения, потребность жрать каждую секунду 24 часа в сутки, 7 дней в неделю.

В школе такому уже не учат?

Зачем вообще такое может понадобиться