Po co niszczyć przy zamykaniu programu?

0

Wiec pytanie jak w temacie.
Po co niszczyć obiekty, zmienne itp. przy zamykaniu programu?
System sam nie usunie wszystkich pozostałości po programie ? Samemu zrobimy to szybciej? Czy może dla wyuczenia sie sprzątania po sobie?

0

http://c-faq.com/malloc/freeb4exit.html

Moim zdaniem jednak lepiej to robić.

0

Czy może dla wyuczenia sie sprzątania po sobie?
Właśnie.

0

Tylko po to, żeby Twój program w czasie działania nie zapełnił całej pamięci komputera.
Na wyjściu rzeczywiście wszystko jest sprzątane.

0

Pytanie powinno brzmiec: po co spuszczac wode po sraniu?

13
Wibowit napisał(a)

Są kible co same się spłukują.
na przykład kibel o nazwie Java ma automatyczny mechanizm spłukiwania. natomiast kibel o nazwie C++ takie ficzera nie ma. znany i szanowany projektant kibli Bjarne S. postanowił dać srającemu wolność, kiedy chce się pozbyć swojej kupy. natomiast zwykle każda nowoczesna ubikacja typu OS ma zatrudnioną babcię klozetową, która po każdym kliencie sprawdza, czy jest na tyle dobrze wychowany, że spuścił po sobie wodę.

właśnie o to dobre wychowanie chodzi.

0
EgonOlsen napisał(a)

Sa tez deski za stodola bez opcji splukiwania, co nie Wibowit?

Wiejskie Sracze to ubikacje dawnego typu, których nie stać na zatrudnienie babci klozetowej

5

Jak byś poczytał link z drugiego posta, to byś wiedział, że free() wcale nie musi uwalniać pamięci.

ATSD:
Automatyczny mechanizm anihilacji gówna jest też w Haskellu, Pythonie, .NETu, PHP, Lispie itp itd Wygląda na to, że trzeba klepać w C/ C++/ Pascalu albo i nawet pod samego asemblera, aby być chociaż trochę kulturalnym, no nie?

0
Wibowit napisał(a)

Jak byś poczytał link z drugiego posta, to byś wiedział, że free() wcale nie musi uwalniać pamięci.

ATSD:
Automatyczny mechanizm anihilacji gówna jest też w Haskellu, Pythonie, .NETu, PHP, Lispie itp itd Wygląda na to, że trzeba klepać w C/ C++/ Pascalu albo i nawet pod samego asemblera, aby być chociaż trochę kulturalnym, no nie?

nie. dzięki automatycznemu mechanizmowi anihilacji gówna w tych kiblach, srający jest zwolniony z przestrzegania reguł savoir-vivre, ma problem z głowy ;)

1

No to mam wygodniej w takim razie :)

0

możesz spróbować defragmentować pamięć. Spróbuj CleanMem lub to: http://www.softpedia.com/get/Tweak/Memory-Tweak/ Ja osobiście nie używam, ale to dlatego, że mam spory zapas. - vpiotr dzisiaj, 12:11

Toż to czyste oszustwo, co ci da swapowanie wszystkiego na dysk i wczytywanie od nowa poza uber lagiem systemu?

Jednocześnie pouczam żeby zachować trochę kultury jednak i nie srać do wątku.

0

Aaa no java to chyba zaczyna sprzątać zanim zdążysz się wysrać? Tak, że już jak wstajesz to od razu czysto.

0

Mi już się zdarzyło, że niezamknięty plik po zakończeniu app nadal taki dla systemu pozostał(win xp) i nie można było go usunąć.

0
byku_guzio napisał(a)

Mi już się zdarzyło, że niezamknięty plik po zakończeniu app nadal taki dla systemu pozostał(win xp) i nie można było go usunąć.

Niemożliwe. Każdy proces posiada tablicę uchwytów, w momencie zamknięcia procesu wszystkie uchwyty są zwalniane przez system, nie ma różnicy pomiędzy ręcznym zamknięciem uchwytu i automatycznym podczas finalizacji. Albo aplikacja nadal gdzieś wisiała jako zombie (np. z powodu podpiętego debuggera), albo inna aplikacja miała otwarty ten plik (np. jakieś rozszerzenie powłoki przy wyświetlaniu zawartości katalogu), NT nie gubi zasobów w ten sposób.

0

Też mnie to zdziwiło, ale xp często miewał takie motki, że blokował plik przed usunięciem jako "używany" (nie koniecznie przez coś co ja pisałem).

2

W takim razie wirus, antywirus, program do backupów, jakieś rozszerzenie eksploratora (jak te od Tortoise*). Gdybyś miał jeszcze taki problem to posłuż się np. handle.exe od Sysinternals:

C:\>handle -u page

Handle v3.46
Copyright (C) 1997-2011 Mark Russinovich
Sysinternals - www.sysinternals.com

System             pid: 4      type: File          ZARZąDZANIE NT\SYSTEM      3CC: C:\pagefile.sys

Ew. możesz dodać -a ponieważ obiekt może być używany inaczej niż bezpośrednio jako plik:

C:\>notepad

C:\>handle notepad.exe

Handle v3.46
Copyright (C) 1997-2011 Mark Russinovich
Sysinternals - www.sysinternals.com

No matching handles found.

C:\>handle -a notepad.exe

Handle v3.46
Copyright (C) 1997-2011 Mark Russinovich
Sysinternals - www.sysinternals.com

csrss.exe          pid: 356    type: Thread         200: notepad.exe(860): 864
csrss.exe          pid: 356    type: Process        2A4: notepad.exe(860)
svchost.exe        pid: 800    type: Process        E48: notepad.exe(860)
notepad.exe        pid: 860    type: Process         80: notepad.exe(860)

Notepad.exe nie usuniesz ponieważ obiekt procesu działa w oparciu o mapowaną sekcję pochodzącą od pliku notepad.exe, chociaż plik nie jest już bezpośrednio otwarty.

Zamiast handle.exe można posłużyć się opcją wyszukiwania w Process Explorerze. Proces SYSTEM zawiera uchwyty stworzone przez kod działający na poziomie jądra systemu, także przez sterowniki.

1
EgonOlsen napisał(a)

A wlasnie ze mozliwe. Na XP to byla normalka. Tak samo zachowuja sie uchwyty zaalokowane i niezwolnione w skryptach Perl o ile dobrze pamietam. Dopiero po wylaczeniu interpretera (nie po zakonczeniu skryptu) uchwyty sa zwalniane dla systemu operacyjnego.

Przecież skrypty Perla nie są samodzielnymi aplikacjami, wykonują się w procesie interpretera, jeśli tam czegoś nie zamkniesz to będzie obciążać tablicę uchwytów interpretera.

0

Automatyczne zwalnianie pamięci bardzo często jest pomocne, jednak gdy zaczynamy bardzo często przydzielać pamięć, a później przestajemy jej używać zamiast ręcznie zwolnić to może się okazać że jej zabraknie. Tutaj szczególnie mówię o obliczeniach na olbrzymich macierzach i symulacjach gdzie tworzona i niszczona jest bardzo często duża ilość obiektów. Przy pisaniu aplikacji gdzie tej pamięci używa się niewiele (ustalmy granicę na powiedzmy 50MB) to automatyczne zwalnianie pamięci jest bardzo przydatne, bo skraca czas pisania i wielkość kodu.

0
krwq napisał(a)

automatyczne zwalnianie pamięci jest bardzo przydatne, bo skraca czas pisania i wielkość kodu.

/facepalm

1
EgonOlsen napisał(a)
krwq napisał(a)

automatyczne zwalnianie pamięci jest bardzo przydatne, bo skraca czas pisania i wielkość kodu.

/facepalm

Logicznie rzecz ujmując jest to prawda.

1

@EgonOlsen nie wiem co ty się tak uparłeś na to że koniecznie sam musisz zwalniać pamięć. czasami człowiek ma ciekawsze rzeczy do roboty niż w obszernym kodzie zastanawianie się czy się wszędzie pamięć zwolniło

0

Jak tak dalej pójdzie, to Egon zostanie sam na placu boju z miotłą do odśmiecania :P

1

W tej materii popieram Egona,bo wolę mieć pełną kontrolę nad tym,kiedy uruchomi się destruktor mojej klasy.Żeby nie było ani mi się śni podważać zalet automatycznych odśmiecaczy,jednak w takiej postaci jak istnieją to jednak są trochę nie teges.
Imo idealne wyjście to włączany na życzenie garbage collector przy pozostawieniu możliwości używania delete w przypadkach,kiedy obiekt trzeba ubić w konkretnie wybranym przez nas czasie.

A skoro mamy łazienkową paralelę-najlepszy byłby kibel z automatycznym spłukiwaniem ale też możliwością wyłączenia tej automatyki,oraz starą dobrą wajchą "zrzucaj bombę" ;)

0

A ja od wczoraj staram sie wyobrazic automatyke fabryki z wbudowanym memory leakiem i okreslic po jakim czasie taka automatyka padnie na ryj ;)
Albo samochod, ktory trzeba co 100km restartowac zeby se komputer pokladowy poczyscil pamiec :D

0
MasterBLB napisał(a)

A skoro mamy łazienkową paralelę-najlepszy byłby kibel z automatycznym spłukiwaniem ale też możliwością wyłączenia tej automatyki,oraz starą dobrą wajchą "zrzucaj bombę" ;)

Takie urządzenie nazywa się auto_ptr. Ale z drugiej strony wszyscy na to klną (kontenery, argumenty funkcji...)
Nie rozumiem dlaczego shared_ptr/shared_array nie może mieć "release". Takie trochę twardogłowe myślenie.

0

Egon:
Czyli te twoje programy nie są w ogóle fault-tolerant? Jakby się gdzieś sterownik wyłożył to już system go automatycznie nie zrestartuje?
A GC nie oznacza wielkich pauz na odśmiecanie. Jest coś takiego jak np Real Time Specification for Java, albo np http://www.azulsystems.com/ - bezpauzowy JVM.

0

W takim razie wirus, antywirus, program do backupów, jakieś rozszerzenie eksploratora

użytkownikowi wszystko jedno co trzyma plik: liczy się fakt, ze próbuje usunąć plik i się wścieka że nie może. brakuje w Windowsie informacji, który proces uniemożliwia usunięcie - na wzór ekranu z aplikacjami blokującymi zamknięcie systemu.

Gdy spotykam się z taką sytuacją, to mnie g…o obchodzi że jakiś proces (zazwyczaj już dawno „zamknięty” lub zawieszony) ma wciąż otwarty uchwyt. Chcę skasować plik. W ostateczności mogłoby wystarczyć oznaczenie do automatycznego późniejszego skasowania.

1 użytkowników online, w tym zalogowanych: 0, gości: 1