Использовать RAII
- Забудьте о сборке мусора (вместо этого используйте RAII). Обратите внимание, что даже сборщик мусора тоже может протекать (если вы забыли обнулить некоторые ссылки в Java / C #), и этот сборщик мусора не поможет вам избавиться от ресурсов (если у вас есть объект, который получил дескриптор для файла, файл не будет освобожден автоматически, когда объект выйдет за пределы области видимости, если вы не сделаете это вручную в Java или не воспользуетесь шаблоном «dispose» в C #).
- Забудьте о правиле «один возврат на функцию» . Это хороший совет C, чтобы избежать утечек, но он устарел в C ++ из-за использования исключений (вместо этого используйте RAII).
- И хотя «Сэндвич-шаблон» - хороший совет для C, он устарел в C ++ из-за использования исключений (вместо этого используйте RAII).
Этот пост кажется повторяющимся, но в C ++ самый простой шаблон, который нужно знать, - это RAII .
Научитесь использовать интеллектуальные указатели, как из boost, 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.
}
Подводя итог (после комментария Ogre Psalm33 ), RAII опирается на три концепции:
- Как только объект построен, он просто работает! Приобретайте ресурсы в конструкторе.
- Достаточно разрушения объекта! Освободите ресурсы в деструкторе.
- Все дело в прицелах! Объекты с заданной областью (см. Пример doRAIIStatic выше) будут созданы при их объявлении и будут уничтожены в тот момент, когда выполнение выйдет из области видимости, независимо от того, как выход (возврат, прерывание, исключение и т. Д.).
Это означает, что в правильном коде C ++ большинство объектов не будут построены с использованием newи вместо этого будут объявлены в стеке. А для созданных с использованием newвсе будет как-то ограничено (например, прикреплено к интеллектуальному указателю).
Как разработчик, это действительно очень эффективно, поскольку вам не нужно заботиться о ручной обработке ресурсов (как это сделано в C или для некоторых объектов в Java, которые интенсивно используют try/ finallyв этом случае) ...
Изменить (2012-02-12)
«объекты с заданной областью ... будут разрушены ... независимо от выхода», что не совсем так. есть способы обмануть RAII. любой вариант terminate () будет обходить очистку. exit (EXIT_SUCCESS) - оксюморон в этом отношении.
- Вильгельмтель
Вильгельмтелл совершенно прав: существуют исключительные способы обмануть RAII, и все они приводят к внезапной остановке процесса.
Это исключительные способы, потому что код C ++ не загроможден символами завершения, выхода и т. Д., Или, в случае с исключениями, мы действительно хотим, чтобы необработанное исключение приводило к сбою процесса и дампу основного образа памяти как есть, а не после очистки.
Но мы все равно должны знать об этих случаях, потому что, хотя они случаются редко, они все же могут случиться.
(кто вызывает terminateили exitв случайном коде C ++? ... Я помню, что имел дело с этой проблемой, играя с GLUT : эта библиотека очень ориентирована на C, доходит до того, что активно разрабатывает ее, чтобы усложнить задачу разработчикам C ++, например, не заботиться о данных , выделенных стеком , или о наличии "интересных" решений о том, чтобы никогда не возвращаться из основного цикла ... Я не буду это комментировать) .