Общие руководящие принципы для предотвращения утечек памяти в [закрытом] C++

Точно один возврат из любой функции. Тем путем можно сделать освобождение там и никогда не пропускать его.

слишком легко сделать ошибку иначе:

new a()
if (Bad()) {delete a; return;}
new b()
if (Bad()) {delete a; delete b; return;}
... // etc.

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

Управляйте памятью тем же путем, Вы управляете другими ресурсами (дескрипторы, файлы, соединения дб, сокеты...). GC не помог бы Вам с ними также.

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

struct myparams {
int x;
std::vector<double> z;
}

std::auto_ptr<myparams> param(new myparams(x, ...));
// Release the ownership in case thread creation is successfull
if (0 == pthread_create(&th, NULL, th_func, param.get()) param.release();
...

Здесь вместо этого функция потока

extern "C" void* th_func(void* p) {
   try {
       std::auto_ptr<myparams> param((myparams*)p);
       ...
   } catch(...) {
   }
   return 0;
}

Симпатичный easyn не так ли? В случае, если создание потока перестало работать, ресурс будет free'd (удаленным) auto_ptr, иначе владение будет передано потоку. Что, если поток так быстр, что после создания он выпускает ресурс перед

param.release();

, называют в основной функции/методе?Ничего! Поскольку мы 'скажем' auto_ptr игнорировать освобождение. Действительно ли управление памятью C++ легко не так ли? С наилучшими пожеланиями,

Ema!

Мы переносим все наши функции выделения со слоем, который добавляет краткую строку в передней стороне и флаг сигнальной метки в конце. Так, например, у Вас был бы вызов к "myalloc (pszSomeString, iSize, iAlignment); или новый ("описание", iSize) MyObject (); который внутренне выделяет указанный размер плюс достаточно пространства для Вашего заголовка и сигнальной метки. Конечно, не забывайте комментировать это для сборок неотладки! Требуется немного больше памяти, чтобы сделать это, но преимущества явно перевешивают затраты.

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

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

Это может также быть сделано во время компиляции путем замены новых операторов и удалить и другие функции выделения памяти.

, Например, регистрация этого сайт [Отладка выделения памяти в C++] Примечание: существует прием для оператора delete также что-то вроде этого:

#define DEBUG_DELETE PrepareDelete(__LINE__,__FILE__); delete
#define delete DEBUG_DELETE

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

Вы могли также попробовать что-то как BoundsChecker в соответствии с Visual Studio, которая довольно интересна и проста в использовании.

valgrind (только польза для *отклоняет платформы), очень хорошее средство проверки памяти

Если Вы собираетесь управлять своей памятью вручную, у Вас есть два случая:

1. я создал объект (возможно, косвенно, путем вызывания функции, которая выделяет новый объект), я использую его (или функция, я называю использование им), затем я освобождаю его.
2. Кто-то дал мне ссылку, таким образом, я не должен освобождать ее.

, Если необходимо нарушить какое-либо из этих правил, зарегистрируйте его.

Это - все о владении указателя.

• Стараются не выделять объекты динамично. Пока классы имеют соответствующих конструкторов и деструкторы, используют переменную типа класса, не указатель на нее, и Вы избегаете динамического выделения и освобождения, потому что компилятор сделает это для Вас.
  На самом деле это - также механизм, используемый "интеллектуальными указателями" и называемый RAII некоторыми из других устройств записи ;-).
• при передаче объектов другим функциям предпочтите параметры ссылки по указателям. Это избегает некоторых возможных ошибок.
• Объявляют константу параметров, если это возможно, особенно указатели на объекты. Тем путем объекты не могут быть освобождены "accidentially" (кроме того, если Вы выбрасываете константу ;-))).
• Минимизируют количество мест в программе, где Вы делаете выделение памяти и освобождение. Например, если Вы действительно выделяете или несколько раз освобождаете тот же тип, запишите функцию для него (или метод фабрики ;-)).
  Этот способ, которым можно создать вывод отладки (какие адреса выделены и освобождены...), легко, при необходимости.
• Использование фабрика функционируют для выделения объектов нескольких связанных классов от единственной функции.
• , Если Ваши классы имеют общий базовый класс с виртуальным деструктором, можно освободить всех их использующих ту же функцию (или статический метод).
• Проверка, которую любит Ваша программа с инструментами, очищает (к сожалению, много $/в‚ ¬/...).

Для MSVC только, добавьте следующее к вершине каждого .cpp файла:

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

Затем при отладке с VS2003 или больше, Вам скажут о любых утечках, когда Ваша программа выйдет (это отслеживает новый/удаляющий). Это является основным, но это помогло мне в прошлом.

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

Valgrind memcheck является превосходным свободным.

Если Вы можете, использовать повышение shared_ptr и стандартный C++ auto_ptr. Они передают семантику владения.

при возврате auto_ptr Вы говорите вызывающей стороне, что даете им владение памяти.

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

Они семантика также относятся к параметрам. Если вызывающая сторона передает Вас auto_ptr, они дают Вам владение.

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

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

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

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

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

Подсказки в порядке Важности:

-Tip#1 Всегда не забывают объявлять Ваши "виртуальные" деструкторы.

smartpointers

-Tip#4 повышения Использования RAII

-Tip#5, Если некоторые случайные / очень важное невыполнение (как в играх с тысячами объектов) взгляд работы на контейнер указателя повышения Thorsten Ottosen

-Tip#6 Находят заголовок обнаружения утечки для Вашей предпочтительной платформы, такой как "vld" заголовок Обнаружения Визуальной Утечки

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

Я полностью подтверждаю весь совет о RAII и интеллектуальных указателях, но я также хотел бы добавить немного высокоуровневую подсказку: самая легкая память для управления является памятью, которую Вы никогда не выделяли. В отличие от языков как C# и Java, где в значительной степени все - ссылка в C++, необходимо поместить объекты на стек каждый раз, когда Вы можете. Поскольку я имею, видят, что несколько человек (включая доктора Stroustrup) указывают, главная причина, почему сборка "мусора" никогда не была популярна в C++, состоит в том, что правильно написанный C++ не производит большого количества мусора во-первых.

не пишут

Object* x = new Object;

или даже

shared_ptr<Object> x(new Object);

, когда можно просто записать

Object x;

Читайте на RAII и удостоверьтесь, что Вы понимаете это.

Вы захотите посмотреть на интеллектуальные указатели, такой как интеллектуальные указатели повышения .

Вместо

int main()
{ 
    Object* obj = new Object();
    //...
    delete obj;
}

повышение:: shared_ptr автоматически удалит, после того как подсчет ссылок является нулем:

int main()
{
    boost::shared_ptr<Object> obj(new Object());
    //...
    // destructor destroys when reference count is zero
}

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

Это не панацея, как бы то ни было. Хотя можно получить доступ к указателю базы, Вы не хотели бы передавать его третьей стороне API, если Вы не были уверены относительно того, что он делал. Много времен, Вашего материала "регистрации" к некоторому другому потоку для работы, которая будет сделана ПОСЛЕ ТОГО, КАК объем создания закончен. Это распространено с PostThreadMessage в Win32:

void foo()
{
   boost::shared_ptr<Object> obj(new Object()); 

   // Simplified here
   PostThreadMessage(...., (LPARAM)ob.get());
   // Destructor destroys! pointer sent to PostThreadMessage is invalid! Zohnoes!
}

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

Используйте , RAII

• Забывает Сборку "мусора" (Используйте RAII вместо этого). Обратите внимание, что даже Сборщик "мусора" может просочиться, также (если Вы забудете "аннулировать" некоторые ссылки в Java/C#), и что Сборщик "мусора" не поможет Вам избавиться от ресурсов (если у Вас будет объект, который получил дескриптор в файл, то файл не будет освобожден автоматически, когда объект выйдет из объема, если Вы не будете делать этого вручную в Java или использовать "расположить" шаблон в C#).
• Забывают "один возврат на функциональное" правило . Это - хороший совет C избежать утечек, но это устарело в C++ из-за его использования исключений (используйте RAII вместо этого).
• И в то время как "Тестовый Шаблон" является хорошим советом C, это устарело в C++ из-за его использования исключений (используйте RAII вместо этого).

Это сообщение, кажется, является повторяющимся, но в C++, самый основной шаблон для знания RAII.

Учатся использовать интеллектуальные указатели, обоих от повышения, TR1 или даже непритязательного (но часто достаточно эффективный) auto_ptr (но необходимо знать его ограничения).

RAII является основанием и безопасности исключения и распоряжения ресурса в C++, и никакой другой шаблон (тестовая система, и т.д.) не даст Вам обоим (и большую часть времени, это не даст Вам ни один).

Посмотрите ниже сравнения RAII и не кода RAII:

void doSandwich()
{
   T * p = new T() ;
   // do something with p
   delete p ; // leak if the p processing throws or return
}

void doRAIIDynamic()
{
   std::auto_ptr<T> p(new T()) ; // you can use other smart pointers, too
   // do something with p
   // WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}

void doRAIIStatic()
{
   T p ;
   // do something with p
   // WON'T EVER LEAK, even in case of exceptions, returns, breaks, etc.
}

приблизительно RAII

Для суммирования (после комментария от [1 124] людоед Psalm33 ) RAII полагается на три понятия: