> Что значит "не проблема CS"? А что тогда "проблема CS"? И, в
> смысле, когда Кнут излагал разные способы менеджить память, и рассказывал как
> ни один из этих способов не решает проблему на 100%, это
> была не CS, а так, лирическое отступление?Интересно, следуя по Кнуту, я должен Тьюринга считать дураком за его "бесконечную" ленту? А теперь представьте, что есть "бесконечная" память, будут у вас проблемы с "менеджить память"?
> Не хреновое такое лирическое
> отступление? Я давно туда заглядывал, но навскидку там не меньше десятка
> страниц посвящено этому. А если ещё вспомнить про обсуждение проблем фрагментации
> кучи, то подозреваю там несколько десятков страниц наберётся. Не много для
> лирического отступления?
Сначала все свалим в "кучу", а потом будем придумывать 1000500 способов разгребания этой кучи, создавая из этого проблемы. Сущность человека такова.
> Обрати внимание на последнее предложение: фундаментальный интерес CS в том, чтобы определить
> что может, и что не может быть автоматизировано.
:) Теория алгоритмов
https://ru.wikipedia.org/wiki/%D0%A2%D0%...
> mm де факто автоматизируется. Может ли он быть автоматизирован или не может
> уже не важно: он _де_факто_ автоматизируется, программист не просит пользователя просматривать
> эпизодически кучу, и решать что там нужно, а что нет. А
> это значит, что mm находится в области интересов CS. В том
> числе и проблема "текучести кучи" находится в области интересов CS.
Если программист не знает оценки "пространственной" сложности собственных алгоритмов, то что тут сказать? Оценка сложности - обязательна!!!
> Представь себе, что у тебя указатель на память хранится в двух разных
> местах. Есть код который обнуляет один из указателей, есть код который
> удаляет второй. В рантайме эти два куска кода могут выполнится в
> произвольном порядке, предсказать заранее невозможно. Как ты будешь решать, в каком
> из кусков кода вызывать free?
Сами говорите, что обнуляете, значить нужно условие проверки на обнуленность одного из указателей и в дополнение еще и обнулить второй указатель.
> Заведёшь ref_count? Окей, указателей больше, и несколько из них являются частью циклов
> в структурах. Что ты будешь делать? weak_ref? Но давай теперь докажи,
> что weak_ref расставлены правильно, и теперь тебе ещё придётся доказывать, что
> у тебя нет use-after-free, в силу неверной расстановки weak_ref. Или ты
> расчехлишь сборку мусора? Окей, докажи теперь, что указатели обнуляются всегда сразу,
> как только память становится ненужной, что никогда не случится такого, что
> ненужный объект переживёт сотню циклов сборки мусора.
В голове все может случиться, и это не проблема CS! А доказывается легко, альтернативным (эффективным) алгоритмом. Вот приведу цитату из вики:
https://ru.wikipedia.org/wiki/%D0%A1%D0%...
"""
Появление висячих ссылок обычно становится следствием неправильной оценки времени жизни объекта: программист вызывает команду удаления объекта до того, как его использование прекратится.
"""
Там же про утечки
"""
Если ссылающейся на объект переменной будет присвоено новое значение и на объект нет других ссылок, он становится программно недоступным, но продолжает занимать память, поскольку команда его удаления не вызывалась. Такая ситуация и называется утечкой памяти (англ. memory leak).
"""
И это все разве проблемы CS? Что только не придумали, чтобы избавить "программиста" от непосредственной работы с памятью, и по мне это не правильно.
> Тебе всё же удалось доказать? Но вот прилетел pull-request, мы его мергнули.
> Что теперь ты будешь делать? Поверишь автору PR, что он всё
> проверил, точна-точна? Или будешь доказывать отсутствие проблем с mm снова? Или
> может у тебя есть способы повторное доказательство провести проще, типа pr
> меняет три строчки кода, и мы на основании него создаём патч
> на доказательство? И нам не надо для этого опять изучать весь
> наш код целиком, чтобы ничего не упустить?
Я лучше буду "верить" в "бесконечную" ленту Тьюринга, и никаких проблем.
> Проблема разрешима в некоторых частных случаях. Скажем, если тебе удастся обойтись стеком
> и не использовать кучу, то проблема решаема.
Какая проблема?????????
>[оверквотинг удален]
> RAII и при этом хранить каждый указатель в единственном числе, то
> проблема решена. Можно эти ограничения ещё ослабить, и тем не менее
> оставить локальность доказательства корректности -- тебе не придётся анализировать весь
> код заново, после каждого патча на две строчки. Но как только
> ты через эти ограничения перешагиваешь, внезапно оказывается, что доказательство теряет
> локальность, и чтобы доказать, что вот этот вот free(p) не приводит
> к double-free, тебе придётся строить рассуждения о том, как ведут себя
> все 100k строк твоей программы, что никакой из возможных входов в
> программу не приводит к тому, что этот free(p) освобождает кусок памяти
> повторно.
Про отладку не слышали?
> Решённая проблема перестаёт быть проблемой. Проблемы же с mm продолжаются, потому что
> проблема не решена в общем случае, и _это_ даёт возможность программисту
> быть квалифицированным специалистом, и выделятся из серой толпы быдлокодеров, которые
> не разобрались в вопросе в достаточной мере и не набили себе
> достаточного количества шишек.
Говорю же проблема в головах, а не в CS. И всякие сборщики мусора, умные ссылки и всякая муть связанная с mm. решают, точнее пытаются решить, не проблему CS, а проблему тех "программистов", которые не представляют как "правильно" работать с памятью и как писать алгоритмы "эффективные" по памяти.
