Хорошая практика для освобождения malloc по завершении программы?

Question

У меня есть простая программа, которая читает кучу настроек ini-файлов в памяти, выделенной динамически (malloc), затем выполняет циклы в течение длительного времени, а затем завершается.Когда я запускаю valgrind, я вижу, что память, которую я выделил для своих строк ini, не освобождается.

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

С другой стороны, мне нравится, когдаВалгринд сильно похлопал меня по спине за то, что я убрал свой собственный беспорядок.Помимо похлопывания по спине ... это хорошая практика, чтобы освободить все malloc'а пространство после завершения (или просто позволить очистить ОС)?Если это так, как я могу отследить, какие из моих указателей указывают на память, выделенную malloc (вместо указания на строковые константы, которые являются значениями по умолчанию), чтобы гарантировать, что я освобождаю нужные вещи?

Answer 1

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

Сегодня вашПрограмма проста.Но завтра кто-то (кто может быть вами) захочет повторно использовать код для чтения и анализа этого INI-файла.И их программа может запускаться часами, днями или месяцами.Сконструировав свой анализатор .ini так, чтобы он имел чистый интерфейс и правильно управлял его памятью, кто-то (кто может быть вами) однажды поблагодарит вас.

Кроме того, вы, вероятно, обнаружите, что он облегчает написание вашего собственного кодапрочитайте и просмотрите сегодня.(О, да, также вещь Valgrind.)

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

Answer 2

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

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

Answer 3

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

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

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

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

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