don’t pay for what you don’t use

shaed_ptr - всего лишь ещё один класс, написанный на С++. один из миллионов других. можно его юзать, можно его не юзать. мы стопицот лет жили без него и всё работало. появился ещё один класс, и ничего не изменилось: хочешь - используй, не хочешь - не используй. а теперь попробуйте отделаться от GC. вот в этом и разница. С++ предоставляет выбор. дальше всё зависит лишь от квалификации программиста.

напиши свою ОС без страничной памяти, например на с++ и не плати.

Неужели достопочтимый дон не использует WeakReference в java?

а теперь попробуйте отделаться от GC. вот в этом и разница

А теперь покажи где я с этим спорил.

Ну и справедливости ради, shared_ptr - это не просто «ещё один класс, один из миллионов других», а «один из классов, входящих в стандартную библиотеку».

Неужели достопочтимый дон не использует WeakReference в java?

Вообще-то, я в первом сообщении уточнил, что пишу на С++. Могу добавить: меня всё (касающееся сабжа) устраивает.

Ну и циклические ссылки GC умеет удалять и без WeakReference.

я и не спорю. просто дополняю.
а в стандартную библиотеку входит много всего, и далеко не всё это работает эффективно. и это ни к чему не обязывает, лишь гарантирует переносимость кода между системами/компиляторами. но С++ как раз тем и хорош, что можно не использовать никакие библиотеки вообще. а вот в жабе так не получится: там либо через библиотеки - либо никак.

Циклические ссылки == серьезные проблемы в архитектуре. Их решить GC не поможет.

Вам бы в Google, объяснить им про их серьезные проблемы в архитектуре и помочь обойтись без засовывания GC в Blink. А то людям пришлось Oilpan пилить.

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

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

Ну да, ну да. Нужно всего лишь послушать LOR-овских аналитиков.

Циклические ссылки == серьезные проблемы в архитектуре

Какие ваши доказательства?

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

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

Нужно больше каменных топоров. Бензиновые пилы для лохов.

про разделение труда слыхал? или ты в своем офисе сам полы моешь?

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

Видите ли, для вынесения своих суждений нужно было бы ознакомиться с предметом. Хотя бы на уровне просмотра презентации про Oilpan.

Для определенных предметных областей наличие графов с циклами — это норма. Создание программных решений для таких предметных областей требует решения проблемы циклических ссылок. Когда-то это может быть легко решено посредством shared_ptr/weak_ptr, когда-то не может (как раз в ситуации с Blink-ом). GC же дает кардинальное решение данной проблемы. С минимальными усилиями разработчика. Но не бесплатно, естественно.

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

да блин, графы с циклами спокойно всегда существовали. и конечные автоматы. и многое другое. как жеж мы жили-то столько лет без этих соплей, ой-вэй?!

Может задачи были попроще и поменьше, а сроки на разработку подлиннее?

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

да всякие были задачи. некоторые посложнее. а сроки всегда выделяются впритык и программистов не спрашивают особо.
наверное, я чего-то не понимаю. мне тут заявляют, что, чтобы вытереть задницу, непременно нужно «разделение труда». другие утверждают, что без подгузников и костылей технический прогресс невозможен. вы вот решили, что мир появился вчера и до вас никто не видел в глаза циклических графов (Кнут, тем временем, набирает обороты в гробу и даже начинает вырабатывать электричество).
я даже не знаю, что я тут сказать. раньше такие задачи решались успешно чуть ли не с помощью перфокарт, а теперь всё вдруг стало так сложно, прямо капец какой-то!

блин, Кнут-то ещё жив. прошу прощения за ранние похороны. надеюсь, его не разобъёт паралич от чтения современного кода.

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

а мне вот лень

мне тут заявляют

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

вы вот решили, что мир появился вчера и до вас никто не видел в глаза циклических графов

Вы явно приписываете мне какие-то свои влажные фантазии.

раньше такие задачи решались успешно чуть ли не с помощью перфокарт, а теперь всё вдруг стало так сложно, прямо капец какой-то!

Вы хотите сказать, что во времена перфокарт кто-то разрабатывал системы, аналогичные современным Интернет-браузерам вроде Chrome, которые постепенно становятся настоящими ОС для разработанного на JavaScript ПО? Да еще в условиях, когда такого рода софт проверяется на прочность сотнями, если не тысячами экспертов и хакеров?

Вы вот Кнута помянули. Не подскажите, у него в языке TeX нужно было использовать ручное управление памятью или как?

при чём тут каменные топоры?

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

я просто предлагаю тех, кому нужны памперсы, отправить подальше от программирования

И почему же ты решил, что oilpan не нужен? Расскажи. Ты провел анализ затрат? На чем базируется твоя уверенность?

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

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

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

ну, вы-то собрались колоть дрова атомным взрывом

Атомным взрывом - это писать на какой-нибудь Agda.

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

Интересно, какие у тебя основания считать, что они не могут, а кто-то другой (ты, к примеру) - можешь? Впрочем, я уверен, ты и на этот вопрос не ответишь.

что, и овощи на борщ вручную режешь? на балконе выращиваешь, коров в подвале держишь?

качество - это философия

качество - это показатель (наряду с прочими). снобизм - это философия

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

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

Как может произойти выход, если мусор не генерируется? Ты же сам сказал, что твоя программа мусор не производит?

Gensym на Common Lisp написала систему мягкого реального времени для управления производственными процессами. Чтобы GC не мешался под ногами, они как раз лисповый код писали таким образом, чтобы память из кучи не использовалась: либо на стэке выделялось, либо в статическом пуле, в который GC не ходит.

Память чиститить вообще бессмысленно, ибо ОС сама все заберёт при уничтожении процесса.

Ничего, что уничтожение процесса может произойти через сутки, когда вся память будет уже скушана?

// Ни разу не фанат GC.

да он и не вызывается. но он существует и жрёт системные ресурсы.

Какие? Такты он не жрёт, если не вызывается. Если памяти системе мало станет, она странички, где неиспользуемый код GC сидит, выгрузит.

И мало того, что он запустится, так он еще и обойдет все существующие объекты(т.к. они все достижимы). А потом еще и мувнит их в другую области памяти, перелопатив ссылки на объекты.

Ну не все - кругом только эфемерные сборщики с поколениями остались. Даже последнее поколение перешерстить и скопировать проблем нет, там главная проблема - с регистрами и верхушкой стэка, ради которых треды приостанавливать надо.

Так по-разному бывает, о том и речь.

Сейчас ты пытаешься в жалких попытках слиться

Не, мне без дураков приятно, что на мои дилетантские рассуждения целый Царь саггрился. В общем даже льстит. Но я с тобой спорить не буду - слишком много букв и я знаю, что дальше будет только больше :)

Братишка, а вот расскажи мне, чем GC лучше shared_pointer'a?

Они тратят такты при каждом использовании. GC тратит такты только при сборке. Кроме того, аллокация памяти под объект в случае с GC - это просто прибавление длины объекта к текущему указателю в пуле. Реклейма совсем не требуется, потому что дырки в пуле исчезнут после сборщика.

На hello world смарт-пойнтеры будут быстрее, но если их в системе миллионы, то GC реально быстрее.

Как может произойти выход, если мусор не генерируется?

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

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

Не знаю, зачем выдумывать новые формулировки. Принцип говорит о том, что если ты не используешь какую-то фичу языка, то ты за нее ничем не платишь.

Я думаю, что в этой фразе надо как минимум уточнить, что такое «используешь», и что такое «платишь». Я это и попытался сделать по своим впечатлениям от аргументов крестовиков.

Они тратят такты при каждом использовании.

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

Правда у подсчёта ссылок есть один плюс - детерминированность.

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

FPGA нонче копейки стоят. Кто не может решить задачу в RTL, без оперционной системы и языка программирования, чтобы она работала в разрешении наносекунд и совсем без памяти, того надо гнать в шею из отрасли.

Ы?

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

Я ничё не понял. Указатель в пуле не движется - GC не вызывается.

«используешь»

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

«платишь»

А тут какие варианты? Расходуешь ресурсы.

Вот не нужна тебе фича какая-то(например, тот же сборщик или проверки какие-то), не используешь ты их, а система на них ресурсы тратит. Значит, принцип нарушен.

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

Сдизассемблируйте дереференс на посмотреть код, чтоль?

Правда у подсчёта ссылок есть один плюс - детерминированность.

Детерменированность чего? На сколько процентов упадёт производительность в софте с миллионом объектов, если все указатели на смарт-пойнтеры перевести?

FPGA нонче копейки стоят. Кто не может решить задачу в RTL, без оперционной системы и языка программирования, чтобы она работала в разрешении наносекунд и совсем без памяти, того надо гнать в шею из отрасли.

а почему бы и нет, сосбно )

А какие тут могут быть трактовки? Используешь в коде

Вот. То есть ты имеешь в виду, что «используешь» означает «явно обозначаешь в коде программы». А можно, например, понимать «используешь» как «принимаешь как данность всегда доступные механизмы языка или рантайма». Допустим, «используешь ленивость хаскелля», «используешь динамичность питона», «используешь принципы ООП смоллтолка», «используешь автоматическое управление памятью явы».

Так и выходит, что твое (и видимо всех плюсовиков) понимание сабжевого принципа сводится к тому, что я четырьмя сообщениями выше написал. С этим я согласен.

а почему бы и нет, сосбно )

Пока вы будете пыхтеть над RTL, десять миллионов индусов выкатят десять тысяч подобных продуктов, сделанных на Java/C#.

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

кому нужны памперсы

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

не надо путать няньку с памперсами

в песочнице вам ничего не угрожает.

Сдается мне, замуж тебе надо и детей рожать :)