Не допускайте утечек ресурсов

Причина

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

Пример (плохой)

void f(const char* name)
{
    FILE* input = fopen(name, "r");
    // ...
    if (something) return;   // плохо: при something == true происходит утечка файлового дескриптора
    // ...
    fclose(input);
}

Предпочтительнее использовать RAII:

void f(const char* name)
{
    ifstream input {name};
    // ...
    if (something) return;   // OK: утечки нет
    // ...
}

Смотрите также: Раздел об управлении ресурсами

Примечание

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

Примечание

Применение профиля безопасности времени жизни устраняет утечки. В сочетании с безопасностью ресурсов, обеспечиваемой RAII, это устраняет необходимость в «сборке мусора» (не генерируя мусора). Объедините это с применением профилей типов и границ, и вы получите полную типо- и ресурсную безопасность, гарантированную инструментами.

Контроль

Там, где это возможно, заменять владельцев дескрипторами ресурсов стандартной библиотеки (как в примере выше). Или помечать владельца с помощью owner из GSL.

• Смотреть на указатели: классифицировать их на не-владельцев (по умолчанию) и владельцев.
• Искать голые new и delete
• Искать известные функции выделения ресурсов, возвращающие сырые указатели (такие как fopen, malloc и strdup)