Действительно ли приемлемо не освободить память

Это не должно вызывать проблемы в определенной ситуации, описал вопрос.

Однако это не точно нормально. Инструменты статического анализа будут жаловаться на это. Самое главное это создает дурные привычки.

, Каково Ваше чувство об этом?

Некоторый O/Ses не мог бы исправить память, но я предполагаю, что Вы не intenting для работы тех O/Ses.

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

Вместо этого я полагаю, что можно породить дочерний процесс, чтобы сделать грязную работу, захватить вывод от дочернего процесса, позволить дочернему процессу умереть как можно скорее после этого и затем ожидать, что O/S сделает сборку "мусора".

Я лично не использовал это, но так как Вы запускаете с нуля, можно хотеть рассмотреть Boehm-Demers-Weiser консервативный сборщик "мусора"

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

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

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

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

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

я почти уверен, что это - оправдание за ленивое программирование. Почему Вы не можете использовать RAII? Это, потому что Вы не хотите отслеживать свои выделения, нет никакого указателя на них, что Вы сохраняете? Если так, как Вы ожидаете использовать выделенную память - всегда существует указатель на нее, который содержит некоторые данные.

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

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

, Если Вы действительно, действительно не может думать о дизайне, где Вы не можете пропустить память, по крайней мере, иметь благопристойность для использования частной "кучи". Уничтожьте ту "кучу" перед выходом, и у Вас уже будет лучший дизайн, если немного 'hacky'.

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

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

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

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

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

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

Смотрят на проекты, такие как WebKit. Их фаза вычисления напоминает Вашу, так как они создают деревья синтаксического анализа для HTML. Они используют интеллектуальные указатели всюду по своей программе.

Наконец: “It’s вопрос стиля †¦ Неаккуратная работа имеет тенденцию быть формированием привычки. ” †“Шелк в Замок Колдовства David Eddings.

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

Joel Coehoorn прав:

Это не должно вызывать проблемы.

Однако это не точно нормально. Инструменты статического анализа будут жаловаться на это. Самое главное это создает дурные привычки.

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

, Если Вы хотите действительно простой путь к свободной памяти, посмотрите понятие "пулов" тот Apache использование .

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

, Если Вы просто спешите или ленивы и срок действия Вашей программы является маленьким относительно того, что это на самом деле выделяет (т.е. выделение 10 МБ в секунду не является маленьким при выполнении в течение 30 секунд).. затем необходимо быть в порядке.

единственный 'благородный' аргумент относительно освобождения выделенной памяти начинается, когда программа выходит.. должен одно свободное все, чтобы сохранить valgrind от жалобы на утечки или просто позволить ОС сделать это? Это полностью зависит от ОС и если Ваш код мог бы стать библиотекой и не коротким рабочим исполняемым файлом.

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

Иногда не освобождение памяти является правильным поступком.

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

• , добавило немного замедления к компилятору, которым мы хотели, конечно, быть максимально быстро.
• занятое место кода
• занявший время, чтобы кодировать и протестировать deallocators
• не нарушило "код, не выполняет лучше, чем 'никакой код'" изречение.

HTH! FWIW, это "вернулось в день", когда память была невиртуальной и минимальной, поля были намного медленнее, и первые два были нетривиальными соображениями.

Мое чувство было бы чем-то как "WTF!!!"

Взгляд на него этот путь:

• Вы выбираете язык программирования, который не включает сборщик "мусора", нам не разрешают спросить почему.

• Вы в основном заявляете, что Вы слишком ленивы для заботы об освобождении памяти.

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

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

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

можно все еще сделать это, если Вы не заботитесь об упомянутых проблемах.

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

Кроме того, что ОС (ядро и/или библиотека C/C++) может принять решение не освободить память, когда выполнение заканчивается, Ваше приложение должно всегда обеспечивать надлежащее освобождение от выделенной памяти как хорошая практика. Почему? Предположим, что Вы решаете расширить то приложение или снова использовать код; Вы быстро войдете в проблему, если код Вы ранее записали пожирателям ресурсов память излишне после окончания ее задания. Это - рецепт для утечек памяти.

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

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

, Если Вы выделяете несколько огромных блоков памяти или много маленьких блоков.

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

Вы абсолютно положительный, код и необходимая память впишутся в 2 ГБ, для системы Win32, включая дыры памяти и дополнение.

В целом я соглашаюсь, что это - плохая практика.

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

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

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

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

Еще одна причина постараться не делать это: репутация. Если Вы не освободите, все, кто поддерживает код, проклянет Ваше имя, и Ваш представитель в компании получит удар. "Можно ли верить, насколько немой он был? Посмотрите на этот код".