Використовуйте RAII
- Забудьте про збирання сміття (замість цього використовуйте RAII). Зауважте, що навіть сміттєзбірник теж може просочитися (якщо ви забудете "звести нанівець" деякі посилання в Java / C #), і що смітник не допоможе вам розпоряджатися ресурсами (якщо у вас є об'єкт, який придбав ручку для файл, файл не буде звільнений автоматично, коли об’єкт вийде із сфери застосування, якщо ви не зробите це вручну на Java або використовуєте шаблон "розпорядження" в 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.
}
Підводячи підсумок (після коментаря Огре Псалма33 ), RAII спирається на три поняття:
- Після того як об’єкт побудований, він просто працює! Набувати ресурсів у конструктора.
- Руйнування об’єктів достатньо! Вільні ресурси в деструкторі.
- Це все про сфери застосування! Об'єкти, що охоплюють область (див. DoRAIIStatic приклад вище) будуть побудовані при їх оголошенні та будуть знищені в момент, коли виконання вийде з області застосування, незалежно від способу виходу (повернення, перерва, виняток тощо).
Це означає, що в правильному коді C ++ більшість об'єктів не буде побудовано з new, а буде оголошено на стеці. А для тих, хто побудований за допомогою new, все буде якось розмальовано (наприклад, прикріплене до розумного вказівника).
Як розробник, це дуже потужно, тому що вам не потрібно буде дбати про ручну обробку ресурсів (як це робиться на C, або про деякі об'єкти на Java, які інтенсивно використовують try/ finallyдля цього випадку) ...
Редагувати (2012-02-12)
"обшиті об'єкти ... будуть знищені ... незалежно від виходу", це не зовсім вірно. є способи обдурити RAII. будь-який аромат терміналу () обійде очищення. вихід (EXIT_SUCCESS) є оксимороном у цьому плані.
- wilhelmtell
wilhelmtell цілком прав щодо цього: Існують виняткові способи обдурити RAII, що призводить до різкої зупинки процесу.
Це виняткові способи, оскільки код C ++ не засмічений терміном завершення, виходу тощо, або, у випадку, якщо винятки, ми хочемо, щоб необроблений виняток збивав процес і ядро скидало його пам'ять, як є, а не після очищення.
Але ми все одно мусимо знати про ці випадки, оскільки, хоча вони рідко трапляються, вони все ще можуть статися.
(хто телефонує terminateабо exitу випадковому коді C ++? ... Пам’ятаю, що довелося вирішувати цю проблему під час гри з GLUT : Ця бібліотека дуже орієнтована на С, підходить до того, як активно розробляти її, щоб ускладнити розробникам C ++ такі речі, як не дбайливі. про стек розподілених даних або про "цікаві" рішення про те, щоб ніколи не повертатися зі свого основного циклу ... я не буду коментувати це) .