- Zapomnij o zbieraniu śmieci (zamiast tego użyj RAII). Zwróć uwagę, że nawet Garbage Collector może przeciekać (jeśli zapomnisz "zerować" niektóre odwołania w Javie / C #) i że Garbage Collector nie pomoże ci pozbyć się zasobów (jeśli masz obiekt, który uzyskał uchwyt do plik, plik nie zostanie zwolniony automatycznie, gdy obiekt wyjdzie poza zakres, jeśli nie zrobisz tego ręcznie w Javie lub użyjesz wzorca "dispose" w C #).
- Zapomnij o zasadzie „jeden zwrot na funkcję” . Jest to dobra rada C, aby uniknąć wycieków, ale jest przestarzała w C ++ z powodu używania wyjątków (zamiast tego użyj RAII).
- I chociaż „Sandwich Pattern” jest dobrą radą w C, jest przestarzały w C ++ z powodu używania wyjątków (zamiast tego użyj RAII).
Ten post wydaje się powtarzalny, ale w C ++ najbardziej podstawowym wzorcem, jaki należy poznać, jest RAII .
Naucz się używać inteligentnych wskaźników, zarówno z boost, TR1, jak i nawet niskiego (ale często wystarczająco wydajnego) auto_ptr (ale musisz znać jego ograniczenia).
RAII jest podstawą zarówno bezpieczeństwa wyjątków, jak i usuwania zasobów w C ++, i żaden inny wzorzec (kanapka itp.) Nie zapewni Ci obu (i przez większość czasu nie da Ci żadnego).
Zobacz poniżej porównanie kodu RAII i kodu innego niż RAII:
void doSandwich()
{
T * p = new T() ;
delete p ;
}
void doRAIIDynamic()
{
std::auto_ptr<T> p(new T()) ;
}
void doRAIIStatic()
{
T p ;
}
Podsumowując (po komentarzu Ogre Psalm33 ), RAII opiera się na trzech koncepcjach:
- Po zbudowaniu obiekt po prostu działa! Zdobądź zasoby w konstruktorze.
- Wystarczy zniszczenie obiektu! Zwolnij zasoby w destruktorze.
- Chodzi o lunety! Obiekty z zakresem (patrz przykład doRAIIStatic powyżej) zostaną skonstruowane w momencie ich deklaracji i zostaną zniszczone w momencie wyjścia z zakresu przez wykonanie, bez względu na sposób wyjścia (powrót, przerwa, wyjątek itp.).
Oznacza to, że w poprawnym kodzie C ++ większość obiektów nie zostanie zbudowana za pomocą newi zostanie zamiast tego zadeklarowana na stosie. A dla tych, zbudowany przy użyciu new, wszystko będzie jakoś scoped (np dołączony do inteligentnego wskaźnika).
Jako programista jest to naprawdę bardzo potężne, ponieważ nie musisz przejmować się ręczną obsługą zasobów (jak to zrobiono w C lub w przypadku niektórych obiektów w Javie, które intensywnie używają try/ finallyw tym przypadku) ...
Edytuj (2012-02-12)
„obiekty z lunetą… zostaną zniszczone… bez względu na wyjście” to nie do końca prawda. istnieją sposoby na oszukanie RAII. jakikolwiek wariant terminate () pominie czyszczenie. exit (EXIT_SUCCESS) jest pod tym względem oksymoronem.
- wilhelmtell
wilhelmtell ma co do tego całkowitą rację: istnieją wyjątkowe sposoby na oszukanie RAII, a wszystkie prowadzą do nagłego zatrzymania procesu.
Są to wyjątkowe sposoby, ponieważ kod C ++ nie jest zaśmiecony zakończeniem, zakończeniem itp. Lub w przypadku wyjątków, chcemy, aby nieobsługiwany wyjątek spowodował awarię procesu i rdzeń zrzucił obraz pamięci tak, jak jest, a nie po wyczyszczeniu.
Ale nadal musimy wiedzieć o tych przypadkach, ponieważ chociaż rzadko się zdarzają, nadal mogą się zdarzyć.
(kto wywołuje terminatelub exitw zwykłym kodzie C ++? ... Pamiętam, że musiałem radzić sobie z tym problemem podczas zabawy z GLUT : Ta biblioteka jest bardzo zorientowana na język C, posuwając się do tego, że aktywnie ją projektuje, aby utrudniać programistom C ++ takie problemy, jak brak troski o danych zaalokowanych na stosie , czy o „ciekawych” decyzjach o nigdy nie powracaniu z ich głównej pętli … Nie będę tego komentował) .