>>"твой код не течёт? Чем докажешь?"
> Оценкой "пространственной" сложности алгоритмов используемых в программе. Текучесть
> памяти это не проблема CS,Что значит "не проблема CS"? А что тогда "проблема CS"? И, в смысле, когда Кнут излагал разные способы менеджить память, и рассказывал как ни один из этих способов не решает проблему на 100%, это была не CS, а так, лирическое отступление? Не хреновое такое лирическое отступление? Я давно туда заглядывал, но навскидку там не меньше десятка страниц посвящено этому. А если ещё вспомнить про обсуждение проблем фрагментации кучи, то подозреваю там несколько десятков страниц наберётся. Не много для лирического отступления?
wikipedia:
> Computer science is the study of algorithmic processes, computational machines and computation itself.[1] As a discipline, computer science spans a range of topics from theoretical studies of algorithms, computation and information to the practical issues of implementing computational systems in hardware and software.[2][3]
> Its fields can be divided into theoretical and practical disciplines. For example,
> [бла-бла-бла]
> The fundamental concern of computer science is determining what can and cannot be automated.
Обрати внимание на последнее предложение: фундаментальный интерес CS в том, чтобы определить что может, и что не может быть автоматизировано.
mm де факто автоматизируется. Может ли он быть автоматизирован или не может уже не важно: он _де_факто_ автоматизируется, программист не просит пользователя просматривать эпизодически кучу, и решать что там нужно, а что нет. А это значит, что mm находится в области интересов CS. В том числе и проблема "текучести кучи" находится в области интересов CS.
> и если бы была она не
> разрешима, то приведите пример где текет память и это невозможно исправить.
Представь себе, что у тебя указатель на память хранится в двух разных местах. Есть код который обнуляет один из указателей, есть код который удаляет второй. В рантайме эти два куска кода могут выполнится в произвольном порядке, предсказать заранее невозможно. Как ты будешь решать, в каком из кусков кода вызывать free?
Заведёшь ref_count? Окей, указателей больше, и несколько из них являются частью циклов в структурах. Что ты будешь делать? weak_ref? Но давай теперь докажи, что weak_ref расставлены правильно, и теперь тебе ещё придётся доказывать, что у тебя нет use-after-free, в силу неверной расстановки weak_ref. Или ты расчехлишь сборку мусора? Окей, докажи теперь, что указатели обнуляются всегда сразу, как только память становится ненужной, что никогда не случится такого, что ненужный объект переживёт сотню циклов сборки мусора.
Тебе всё же удалось доказать? Но вот прилетел pull-request, мы его мергнули. Что теперь ты будешь делать? Поверишь автору PR, что он всё проверил, точна-точна? Или будешь доказывать отсутствие проблем с mm снова? Или может у тебя есть способы повторное доказательство провести проще, типа pr меняет три строчки кода, и мы на основании него создаём патч на доказательство? И нам не надо для этого опять изучать весь наш код целиком, чтобы ничего не упустить?
Проблема разрешима в некоторых частных случаях. Скажем, если тебе удастся обойтись стеком и не использовать кучу, то проблема решаема. Если тебе удастся обойтись RAII и при этом хранить каждый указатель в единственном числе, то проблема решена. Можно эти ограничения ещё ослабить, и тем не менее оставить локальность доказательства корректности -- тебе не придётся анализировать весь код заново, после каждого патча на две строчки. Но как только ты через эти ограничения перешагиваешь, внезапно оказывается, что доказательство теряет локальность, и чтобы доказать, что вот этот вот free(p) не приводит к double-free, тебе придётся строить рассуждения о том, как ведут себя все 100k строк твоей программы, что никакой из возможных входов в программу не приводит к тому, что этот free(p) освобождает кусок памяти повторно.
Решённая проблема перестаёт быть проблемой. Проблемы же с mm продолжаются, потому что проблема не решена в общем случае, и _это_ даёт возможность программисту быть квалифицированным специалистом, и выделятся из серой толпы быдлокодеров, которые не разобрались в вопросе в достаточной мере и не набили себе достаточного количества шишек.
