Wycieki pamięci i ich negatywny wpływ na system

Witajcie,
Mam taki oto problem nad którym już zastanawiam się od dłuższego czasu.

Jest taka klasa:

TxxxClass = class
  private
    FObiekt: TxxxxxCokolwiek;
 public
    constructor Create;
end;

W creacie tworzymy FObiekt, destruktora nie ma, to celowe.
Klasa TxxxClass tworzona jest tylko i wyłącznie jeden raz w ciągu życia aplikacji (coś ala singleton, choć nie do końca), czyli w trakcie działania aplikacji wycieków nie ma, bo obiekt raz utworzony nadal istnieje i żyje.

I teraz pytanie.
Przy zamknięciu aplikacji gdy wywołam TxxxClass.Free to FObiekt nie zostanie zwolniony. Czy to ma jakiś negatywny wpływ na system (Windows)? Czy to jest tak że pomimo że ten obiekt istnieje wycieku nie ma bo aplikacja działa w jakimś tam obszarze pamięci który zostaje w całości "zaorany" po aplikacji po jej zamknięciu i nie ma się czym przejmować?
Nie twierdzę że ten sposób postępowania jest OK ale mam mały zakład pomiędzy dwoma programistami o kratę browaru ....

Aż tak biegły z windows api nie jestem aby Ci jednoznacznie na to odpowiedzieć ALE bazując na moim doświadczeniu wielokrotnie spotkałem się z tym, że np tworząc jakaś zmienną / obiekt adres, który został mu przyznany zawiera już jakieś dane. Od tego czasu zawsze zmienne inicjalizuję domyślnymi danymi przeważnie w konstruktorze. Nie mniej jednak jeśli tworzysz obiekt na początku aplikacji i masz pewność, że będzie jego tylko jedna instancja, to nie powinno być problemu.

Prawda jest taka że jeżeli proces zostaje zamknięty to Windows zwolni jego pamięć ale czy OK to tak jakby stwierdzić że np. że zawsze wyrzucasz śmieci gdzie się da bo są ludzie którzy posprzątają.

Taka klasa już ma destruktor, to że nie nadpisujesz go i nie zwalniasz FObiekt w nim to inna sprawa. Kiedyś może się okazać że rozbudujesz ten projekt i będzie potrzebne kilka takich klas oraz ich podmiana, więc również to zwolnienie, ale kiedy dojdzie do tej rozbudowy już nie będziesz pamiętać że akurat w tej klasie nie zrobiłeś porządnie destruktora, więc będziesz sobie szukać wycieku jakieś załóżmy 8 godzin. Uwierz mi, nie opłaca się oszczędzenie 20 sekund na niepisaniu destruktora kiedy to powoduje ryzyko stracenia 8 godzin. Obecnie jestem powiedzmy bardzo doświadczony i gdyby mi się zdarzył taki wyciek to znalazłbym go raczej w 10 min lub mniej ale nadal nie pozwolę sobie zrobić klasę bez porządnego destruktora.

Słuchajcie, ja wiem o tym że to jest w ogóle bee nie nadając obiektowi destruktora i naprawdę osobiście po sobie sprzątam obiekty.
Nie chciałem aby dyskusja zeszła na tory używać/nie używać zwalniania obiektów. Tutaj schemat postępowania jest jeden, coś powołałeś do życia to ubij to na koniec.
Interesuje mnie sytuacja gdy obiekt jest utworzony w ramach aplikacji i sama aplikacja jest zabijana. Obiekt zostaje w pamięci, a pamięć jest .. ?? i co dalej z tym obiektem ? Jest wyciek/nie ma wycieku?

Oczywiście, że wyciek będzie. Alokujesz pamięć, której nie zwalniasz. Windows pewnie coś tam zwolni, ale to jest sytuacja, o której pisze Dragon. Windows nie wie, co to za obiekt, więc pewnie potraktuje go jako wskaźnik i zwolni pamięć zajmowaną przez ten wskaźnik. Ale jeśli FObject alokuje sobie jeszcze więcej pamięci (a tak raczej na pewno się dzieje), to ta dodatkowa pamięć nie zostanie już zwolniona. Efektem tego może być mniej pamięci do użycia albo jakieś problemy z pamięcią później lub inne niezdefiniowane, dziwne zachowania. Zawsze taki obiekt należy zwolnić w odpowiedni sposób.

FiTepsa napisał(a):

Interesuje mnie sytuacja gdy obiekt jest utworzony w ramach aplikacji i sama aplikacja jest zabijana.
W większości systemów zabicie procesu wiąże się z zabiciem wszystkich zasobów przez niego rezerwowanych od pamięci przez pliki po porty.