don’t pay for what you don’t use

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

Страничную память предоставляет тебе архитектура железа и ОС. Компилятор тут не причем.

Языки без GC щас используют либо системщики, либо мазохисты, нэ?

Нэ. C++ успешно используется для написания разнообразного десктопного софта, игр.

Дело не в том, что я плачу за то, что использую (пусть даже насильно), а в том, что я не могу отказаться от использования и не платить.

«pay for what you use» и «don’t pay for what you don’t use» - разные фразы и смысловая нагрузка у них разная.

Я хотел донести аналогичную мысль. Что проверку на выход за границы массива предоставляет архитектура JVM. И компилятор тут не при чём.

Этот девиз верный, но кресты, высранные недоумком и двоечником страусом ему не соответсвуют.

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

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

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

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

И пофиг, в языке или в самостоятельно реализованном классе - при проверке в runtime избавится от лишних ассемблерных инструкций не получится.

Что делать с совместимостью с С-интерфейсами и библиотеками, которые передают *void?

GC может и должен быть частью любого нормального языка (опять же отключаемым).

C++ имеет explicit GC: smart-pointers. Также есть автовызов деструкторов для объектов, которые выходят из зоны видимости.

Ты же говоришь о implicit GC.

Но недоносок страус очевидно ниасилил всего этого и поэтому все 30 лет вешает лапшу на уши своим девизом.

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

Он не различает explicit GC и implicit GC. Он говорит о каком-то «нормальном» GC, подразумевая implicit GC. Что взять с дилетанта...

JVM - это часть языка. Когда мы пишем код на Java - мы получаем байткод, который исполняет JVM, так? Вот трансляция и исполнение в JVM со всеми его проверками - это и есть тот оверхед, который нельзя отключить. В случае же С или C++ мы получаем самые обычные процессорные инструкции. Я могу посмотреть, как процессор будет выполнять тело написанной мною функции и гарантируется что он будет выполнять только то, что я написал. Никаких лишних проверок, ни лишних данных. И это даже при сборке без оптимизации.

глючный кал с глистами выходит

C++ имеет explicit GC: smart-pointers. Также есть автовызов деструкторов для объектов, которые выходят из зоны видимости. Ты же говоришь о implicit GC.

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

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

Опять искать стороннее или изобретать свой собственный array. Ваш недоношенный C++ с размерной моделью гоняет объекты по стеку и куче с охрененным оверхедом, а вы про лишние инструкции говорите.

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

Мусор - это грубо говоря все объекты, под которые память выделена, но живых ссылок на которые не осталось. Понятно, что иногда можно делать все вычисления in-place, на один раз выделенном большом массиве например, тогда действительно будет «не создавая мусора вообще».

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

А, я понял, в чем причина недопонимания. Хинт: если у тебя все эти вычисления не выведут потребляемую память за границы, определенные в настройках ВМ, то ГЦ и не запустится. Похоже, что очень многие думают, что в яве ГЦ запускается насильно каждые n мс и всем досаждает m мс, независимо от ситуации с памятью в ВМ. А это не так.

В спецификации Java.

Тем, что не несёт оверхеда на копирование ссылок(ну иногда таки несёт, но мало) и тем, что разруливает проблему циклических ссылок без участия программиста.

Но принцип нулевой стоимости нарушает.

Сборщик мусора может быть реализован в виде библиотеки. Консервативный уже существует. Если пользователи библиотеки согласятся на использования специальных типов указателей(+ сырые указатели только через некий pin_ptr), то можно реализовать сборщик любого вида.

Нужны разные виды gc в библиотеках

В стандарте vector все проверяет в методе at. Не надо ничего велосипедить.

Ваш недоношенный C++ с размерной моделью гоняет объекты по стеку и куче с охрененным оверхедом

Что ты несешь? Давай подробности, а то пока бред выходит.

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

Я знаю, что такое мусор :)

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

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

А чего им не выходить? Я иногда почти всю память юзаю, скажем гигов под 100 какие-нибудь расчеты могут выжрать. И это только на одном серваке. Я могу настроить jvm так, чтоб сборщик в принципе не запускался? Но при этом я должен иметь возможность какими-то пулами управлять так или иначе.

В фотошопах тоже по уму только ядро и GUI имеет смысл писать на системных язычках, а все алгоритмы - на нормальных скриптовых (Ф)ЯП.

Ага, щаз, в фотошопе как раз алгоритмы вплоть до асма оптимизируют

Ты платишь за то, что используешь (возможности автоматического управления памятью).

Возможность и использование — немного разные вещи. ГЦ может и гибко настраивается, но избавиться от него нельзя иначе как через убогий JNI (а это всё равно уже не жаба). Вы в курсе, что в разработке игр под мобилки на Java разработчики когда-то постоянно использовали трюки типа создания статических массивов и расположения всех объектов в них чисто для того, чтобы реже срабатывал сборщик мусора? Вот это и есть плата за то, что в геймдеве под слабые телефоны нахрен никому не надо было.

JVM с JIT-компиляцией или без неё — тоже недешёвая плата за ненужную программисту вещь.

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

Глупый вопрос. А разве в джаве уже убрали ограниченее на 1,5 гига памяти на один процес?

Проверка диапазонов массива — зачем?! Кто вообще придумал такой бред?

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

А разве в джаве уже убрали ограниченее на 1,5 гига памяти на один процес?

AFAIK, оно было только в 32-битной JVM, и то не на всех платформах.

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

недешёвая плата за ненужную программисту вещь.

Зачем вообще такие категоричные заявления? Программисты разные бывают, и разные вещи пишут. Если программист пишет веб-приложение или учетную систему уровня предприятия (хоть самую простую) с числом слоев больше 1 - ему нет смысла рассматривать вариант крестов, потому что нужно думать об архитектуре, бизнес-логике, интеграции и т.д., а не о том, сколько где памяти выделено и освобождено. Ему нужно, чтобы у него была однообразная среда исполнения, не требующая учета нижележащей платформы и особенностей оборудования; чтобы в стандартной библиотеке было побольше полезных высокоуровневых механизмов; чтобы была изкоробочная конкурентность/распределенность; чтобы была инфраструктура, облегчающая сборку, деплой, тестирование, профилирование всего этого дела; и т.д. То, что вся эта хрень невостребована при написании драйверов (а вопросы освобождения памяти и количества используемых тактов процессора - востребованы), не отменяет ее необходимости в других условиях, и никто не будет велосипедить Java EE на крестах только потому что там больше контроль за выделяемой памятью. Мне почему-то кажется, что я объясняю причины того, что дважды два - четыре.

Гже таких дебилов делают?

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

нянька сопли утирать, а GC подбирать за ним мусор

lol

Да ты опять говоришь о выборе между языками. А это не относится к теме. Принцип или поддерживается языком(C, C++, D(отчасти), Rust(?)) или нет(почти все остальные языки).

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

Да ты опять говоришь о выборе между языками.

Так ты все верно пишешь, только не в тему.

Мне показалось, что сама дискуссия уже несколько ушла «не в тему» :) Ну если спорить не о чем, то ладно.

Если ты согласен, что java не следует принципу нулевой стоимости, то я не вижу о чем спорить.

Если ты согласен, что java не следует принципу нулевой стоимости

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

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

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

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

Ты сам говоришь «проверяет», т.е. код проверки пишется вручную и эта проверка необходима. Т.е. нет таких случаев, где намеренно бы программисту хотелось записать что-то за границу массива. Тогда зачем отказываться от автоматической проверки этого действия? Накладные расходы? ОК, но только если в рантайме. В compile-time, например, таких проблем не будет. В итоге, *лучшим* языком окажется тот, который умеет проверку границ, но которая по максимуму делает это в compile time, а что делается в run time может быть отключено. C/C++ не делают вообще ничего, и поэтому лучшими считаться не могут.

В итоге, *лучшим* языком окажется тот, который умеет проверку границ, но которая по максимуму делает это в compile time

Это невозможно, к сожалению. Т.е. можно сделать что-то более-менее работающее на зависимых типах, но это АД. Есть еще всякие системы проверки контрактов времени компиляции, но там тоже все не гладко.

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

C/C++ не делают вообще ничего

Почему это? Разные типы и операции для разных задач. В C++, например, у std::vector есть метод at, который проверяет выход за границы и генерирует исключение.

Ты сам говоришь
сам

Это тян.

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

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

Ты по-моему не понял, в чем мой пойнт. Я не говорил, что на яве можно делать то же, что на цпп.

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

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

Ты не спорил - ты делил один свой выхлоп на ноль вторым, основывая своё на выводах, обоснованность которых ты не доказал. Т.е. балабол.

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

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

Давай я тебе даже поясню, а то вдруг ты реально не понимаешь в чем твоя ошибка:

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

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

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

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

Еще раз. Когда ты выбираешь, на яве или на плюсах тебе решать задачу, у тебя два варианта сочетаний «фича/кост»:

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

Цпп обладает всеми фичами жабки по причине возможности их реализации. Тут есть ещё одна возможность у балаболов юлить, т.е. подменять понятие фича, как возможность к реализации и фича, как реализованная возможность.

Цпп так же обладает минимум ограничений на уровне софтварной реализации, в отличии от жабки. Т.е. возможность к решению у цпп будет ВСЕГДА оптимальней жабки.

А как это реализует так или иная обезьяна - это не суть. И тут ещё одно поле для юлежа и подмены понятий.

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

Я уже рассказывал про это. Очередная подмена понятий.

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

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

Скудоумие так и прёт.

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

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

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

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

Поэтому никто и не пытается доказать это равенство - строитель==ашот, ибо даже для того, что бы его выявить нужно «хотябы iq < 3%».

Логика и обобщённое мышление жабистам недоступно, хотя вроде как ООП во все поля. Связывать причину и следствие, видеть, что твои выводы построены на утверждениях явных/не явных, который ты даже не пытаешься доказать. Вернее вы даже их не видите, ибо мышление настолько шаблонно, что вы воспринимаете их уже как реальность.

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

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

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

Про баги в логике ты наверное перепутал, жабка не избавляет тебя от багов в логике.

Ну и толкать мифцы про настройку гц - мило.

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

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

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

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

Ещё один вылез, эксперт.

Скудоумие - отсутствие логики - отсутствие связности в выводах.

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

Ну и смелое утверждение, что кто-то делает что-то лучше - прям вся суть. Зачем вы толкаете какие-то невнятные равенства, аля «ваятель - неквалифицированная обезьяна», либо «человек - идиот».

Тут так же самая проблема, вернее проблема созданная отсутствием квалификации пытается быть выдана за какую-то реальную проблему, в целям вуалирования своей некомпетентности.

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

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

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

Тем более второй юзкейс в недоязычках уже давно вытеснили ассоциативные массивы.

Дыра в логике - это нет фильтров внешнего мира, либо просто код говно.

Т.е. эта проверка - повод спихнуть ответственность на кого-то.

В итоге, *лучшим* языком окажется тот, который умеет проверку границ

Толку от проверки в компилтайме в районе нуля. И то в основном это проверки логики, а не выхода(об этом я уже говорил выше).

Лучшим для обезьяны - да.

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

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

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

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

http://www.brpreiss.com/books/opus5/html/page426.html

When the memory in the active region is exhausted, the program is suspended and the garbage-collection algorithm is invoked. The stop-and-copy algorithm copies all of the live objects from the active region to the inactive region. As each object is copied, all references contained in that object are updated to reflect the new locations of the referenced objects.

Интел даже подобное процессорное расширение пилит, так сильно индустрии это нужно.

Они когда-то уже пытались что-то такое сделать

https://en.wikipedia.org/wiki/Intel_iAPX_432

О-кей. Вот я в C++ вылез за границы массива и получил segfault, т.к. у меня страница не отображена в память.

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

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

А теперь покажи мне слово «программировал» в «don’t pay for what you don’t use».

И да, что ты за неё платишь? Поподробней.

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

Об этом тебе и я рассказать могу: отсутствием проблем с циклическими ссылками, например.

P.S. Пишу на С++.

Но ведь проблемы с циклическими ссылками бывают только у ребят, которые уже создали себе ПРОБЛЕМЫ с архитектурой. weak_ptr решает.

weak_ptr

Ну то есть ты не споришь тем, что shared_ptr, сам по себе, не замена ГЦ.

Но вообще это спор ни о чём. Думаю, что ты прекрасно понимаешь разницу: одна, да ещё и неявная (в большинстве случаев) сущность против двух (а на самом деле, больше) явных.

если у обжабков клешни не позволяют писать на с++ это значит лишь что обжабки раки.