Утечки памяти в C++ (через new+delete)

Если вы имели в виду «в исходном коде», то №

См. Этот код:

int main()
{
    char* buffer = 0; 


    for( int i = 0; i < 42; ++i )
    {
        buffer = new char[1024];
    }

    delete [] buffer; 

    return 0;
}

1 новый, 1 удаленный, ((42 - 1) * 1024) байтов утечка памяти.

Если вы имели в виду «вызов нового и удаления во время выполнения», тогда да. Каждая память, полученная с помощью new, должна быть освобождена с помощью delete:

int main()
{
    std::vector<char*> bufferList; // or nullptr or NULL whatever


    for( int i = 0; i < 42; ++i )
    {
        bufferList.push_back( new char[1024] );
    }

    for( int i = 0; i < bufferList.size(); ++i )
    {
        delete [] bufferList[i]; 
    }

    return 0;
}

Теперь при выполнении мы получили удаление, выполняемое для каждого нового выполнения <=> без утечки.

Да. Каждое новое должно сопровождаться удалением.

Однако удаление часто скрыто от вас - например:

{
  std::auto_ptr p( new Foo );
}

Здесь есть новое, но удаление (которое происходит автоматически в конце блока) скрыт в реализация std :: auto_ptr.

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

Не совсем так. Любой объект, выделенный с помощью оператора new, должен быть освобожден с помощью оператора удаления. Хорошо иметь несколько операторов (new или delete) в разных ветках.

Лично я использую boost shared_ptr при написании кода на C ++.

Если вы хотите найти предварительный способ обнаружения утечек памяти, подсчет новых / удалений не поможет. Однако, если вы используете MS VC, вы можете использовать CRT для выполнения очень простого, но полезного для вас обнаружения утечек:

_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT);
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

Это заставит CRT вызвать _CrtDumpMemoryLeaks прямо перед выгрузкой CRT. Если они есть, они будут сброшены на консоль:

Detected memory leaks!
Dumping objects ->
{342} normal block at 0x05A28FD8, 4 bytes long.
 Data: <    > 00 00 00 00 
Object dump complete.

Существует также методика определения точного места утечки по номеру блока ({342}), но иногда достаточно знать, есть ли там есть какие-либо утечки.

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

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

Вы спрашиваете о количестве вызовов во время выполнения (например, подсчитанном с помощью инструментального профилировщика)? Точно одинаковое количество обращений к операторам new (исключая размещение new) и delete не является ни необходимым, ни достаточным условием отсутствия утечек кода:

• Удаление NULL безвреден, поэтому многие программы без утечек вызывают delete чаще, чем new .
• Программа, которая вызывает delete столько раз, сколько new , но иногда удаляет NULL , имеет утечку. То же самое и с некоторыми программами, которые вызывают delete чаще, чем new , но иногда удаляют NULL .
• Программа, которая чаще вызывает new чем delete имеет утечку.

Чтобы убедиться в отсутствии утечек, вы должны убедиться, что каждый адрес, возвращаемый из new , передается в delete , а не просто убедитесь, что количество вызовов совпадает. И даже это упрощение, поскольку адреса повторно используются для множественного распределения.

Кроме того, программы, которые не пропускают выделенную ими память, могут по-прежнему пропускать другие ресурсы (например, дескрипторы файлов ОС).

То же самое и с некоторыми программами, которые вызывают delete чаще, чем new , но иногда удаляют NULL .

Программа, которая чаще вызывает new чем delete имеет утечку.

Чтобы убедиться в отсутствии утечек, вы должны убедиться, что каждый адрес, возвращаемый из new , передается в delete , а не просто убедитесь, что количество вызовов совпадает. И даже это упрощение, поскольку адреса повторно используются для множественного распределения.

Кроме того, программы, которые не пропускают выделенную ими память, могут по-прежнему пропускать другие ресурсы (например, дескрипторы файлов ОС).

То же самое и с некоторыми программами, которые вызывают delete чаще, чем new , но иногда удаляют NULL .

Программа, которая чаще вызывает new чем delete имеет утечку.

Чтобы убедиться в отсутствии утечек, вы должны убедиться, что каждый адрес, возвращаемый из new , передается в delete , а не просто убедитесь, что количество вызовов совпадает. И даже это упрощение, поскольку адреса повторно используются для множественного распределения.

Кроме того, программы, которые не пропускают выделенную ими память, могут по-прежнему пропускать другие ресурсы (например, дескрипторы файлов ОС).

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

Кроме того, программы, которые не пропускают выделенную ими память, могут по-прежнему пропускать другие ресурсы (например, дескрипторы файлов ОС).

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

Кроме того, программы, которые не пропускают выделенную ими память, могут по-прежнему пропускать другие ресурсы (например, дескрипторы файлов ОС).

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

Вам необходимо сопоставить количество вызовов новый с количеством вызовов удалить .

Чаще всего это усложняется, что это.

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

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

Вам необходимо сопоставить вызов для нового с вызовом для удаления. Поскольку C ++ является объектно-ориентированным языком программирования, рассмотрите возможность использования класса для создания (в конструкторе) и удаления (в деструкторе) переменных, объявленных или используемых в классе. Фактически, это будет использование преимущества идиомы Resource Acquisition Is Initialization или RAII (для краткости). Если вам не хочется программировать это самостоятельно, вы всегда можете использовать память из STL .

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