Утечки памяти, когда-нибудь в порядке? [закрытый]

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

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

польза только с выходом из приложения:

1. ОС получает один блок к свободному вместо многих много маленьких блоков. Это означает, что завершение работы намного намного быстрее. Особенно в Windows с он - медленное управление памятью.

плохими только с выходом являются на самом деле две точки:

1. легко забыть высвобождать средства, которые ОС не отслеживает или что ОС могла бы ожидать немного с выпуском. Одним примером являются сокеты TCP.
2. программное обеспечение отслеживания Памяти сообщит все не освобожденный в выходе как утечки.

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

Только в одном экземпляре: программа собирается застрелиться из-за неисправимой ошибки.

Похоже, что Вашим определением "утечки памяти" является "память, которую я не очищаю сам". Все современные Ose освободят его на выходе программы. Однако, так как это - вопрос о C++, можно просто обернуть рассматриваемую память в соответствующем std::auto_ptr, который будет звонить, удаляют, когда она выходит из объема.

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

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

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

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

Некоторые, если () свободный () вызовы в функции очистки являются дешевыми, почему бы не использовать их?

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

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

1. Ваша библиотека, которая не очищает ее память до выходов процесса.
2. Вы пишете дополнительным 500 строки кода и добавляете другое взаимное исключение и условную переменную к Вашему классу так, чтобы это могло закрыться чисто от Ваших тестов †“, но этот код никогда не используется в производстве, где сервер только завершается путем катастрофического отказа.

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

Это помогает сделать отчет об утечке более полезным... и не переполненное "динамическим выделением в статическом контексте не free'd выходом программы"

При использовании его вплоть до хвоста Вашего main() это - просто не утечка (принимающий защищенную систему памяти, конечно!).

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

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

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

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

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

В общем, лучше устранить утечки памяти.

Некоторое время назад я бы сказал да, что когда-то было приемлемо допустить утечку памяти в вашей программе (она все еще находится на стадии быстрого прототипирования), но, сделав сейчас в 5 или 6 раз больше опыта, отслеживание даже малейшей утечки выявило некоторые действительно серьезные функциональные ошибки. Допуск утечки в программе происходит, когда жизненный цикл объекта данных на самом деле неизвестен, что свидетельствует о полном отсутствии анализа. Итак, в заключение, всегда полезно знать, что происходит в программе.

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

Используйте какой-нибудь умный указатель, который сделает это за вас автоматически (например, scoped_ptr из Boost libs)