Czy istnieje powód, aby wywoływać usuwanie w C++, gdy program jest mimo to zamykany?

Question

W mojej funkcji C++ main, na przykład, gdy miałem wskaźnik do zmiennej, która używa pamięci sterty (w przeciwieństwie do pamięci stosu) - czy jest ona automatycznie deallocated po wyjściu mojej aplikacji? Zakładam, że tak.

Mimo to, czy dobrą praktyką jest zawsze usuwanie przydziałów sterty, nawet jeśli uważasz, że nigdy nie zostaną użyte w sytuacji, gdy pamięć zostanie automatycznie zwolniona przy wyjściu?

Czy na przykład ma to jakiś sens?

int main(...) 
{ 
    A* a = new A(); 
    a->DoSomething(); 
    delete a; 
    return 0; 
} 

Myślałam być może w przypadku I byłaby (lub ktoś inny refactors) ten kod i umieszcza go w innym miejscu aplikacji, gdzie delete jest naprawdę neccecary.

Oprócz odpowiedzi Briana R. Bondy (która mówi konkretnie o implikacjach w C++), Paul Tomblin ma także good answer to a C specific question, który również mówi o destruktorze C++.

Answer 1

Ważne jest, aby jawnie wywoływać usuwanie, ponieważ możesz mieć kod w destruktorze, który chcesz uruchomić. Jak może zapisanie niektórych danych do pliku dziennika. Jeśli pozwolisz systemowi zwolnić twoją pamięć, twój kod w twoim destruktorze nie zostanie wykonany.

Większość systemów operacyjnych zwolni pamięć po zakończeniu programu. Ale dobrym zwyczajem jest zwalnianie go samemu i jak już powiedziałem, system operacyjny nie nazwałby twojego destruktora.

Jeśli chodzi o wywoływanie delete w ogóle, tak zawsze chcesz wywołać delete, inaczej będziesz miał wyciek pamięci w swoim programie, co spowoduje niepowodzenie nowych przydziałów.

Answer 2

Pomyśl o swojej klasie A konieczności zniszczenia.
Jeśli nie zadzwonisz pod numer delete pod adresem a, ten destruktor nie zostanie wywołany. Zwykle nie ma to znaczenia, jeśli proces się zakończy. Ale co jeśli destruktor musi zwolnić, np. obiekty w bazie danych? Przepłukać pamięć podręczną do pliku dziennika? Napisz pamięć podręczną z pamięcią na dysk?

Widzisz, nie jest to tylko "dobra praktyka" do usuwania obiektów, w niektórych sytuacjach jest to wymagane.

Answer 3

Weź pod uwagę przypadek, w którym obiekt do usunięcia uzyskał zewnętrzny zasób, którego system nie może bezpiecznie uwolnić. Jeśli nie wywołasz delete na tym obiekcie, masz prawdziwy wyciek.

Answer 4

zawsze upewnij się, że sam go usunąłeś. System operacyjny zajmie się tym, ale wyeliminuje błędy, których można łatwo uniknąć.

Answer 5

Tak, pomaga wyeliminować fałszywe alarmy po uruchomieniu programu za pomocą narzędzia do wykrywania wycieków pamięci.

Answer 6

Innym powodem wyraźnie usuwanie obiektów jest to, że jeśli aplikacja ma prawdziwy przeciek pamięci, staje się łatwiejsza w użyciu narzędzi, takich jak valgrind znaleźć przecieki, jeśli nie trzeba przesiać przez „przecieki”, które pochodzą z nie przeszkadza posprzątać.

Answer 7

Kolejnym powodem do usunięcia jest uniknięcie fałszywych alarmów z wykrywacza nieszczelności, z których można korzystać w przyszłości. Jeśli masz fałszywe alarmy, możesz nie zwracać uwagi na prawdziwy wyciek zgłaszany przez wykrywacz nieszczelności - zostanie zakopany wśród fałszywych w raporcie.

Answer 8

Tak.

• Standard nie gwarancję że system operacyjny będzie oczyścić pamięć. Możesz się tego spodziewać na platformach głównego nurtu, ale dlaczego skorzystać?
• Unikasz bałaganu zgłaszanego przez narzędzia takie jak valgrind, jeśli celowo nie wyciekniesz z pamięci.
• Jeśli wpadniesz w ten nawyk, kto powie, że pewnego dnia przypadkowo nie zastosujesz tego podejścia, to ma to znaczenie?
• You może potrzebujesz zniszczenia obiektu. Zwykle po prostu zakładaj, że to robisz. To cię nie boli.