Deleta pekare

Måste man deleta pekare i slutet av programmet eller spelar det ingen roll?

Pekaren kommer att gå ur scope då programmet avslutas. Dock brukar man alltid städa upp efter sig innan man avslutar. Sen finns det ju saker som är tänkt att gå hela tiden, t ex en service (Windows då alltså) och då är det extremt viktigt att ha koll på allt minna man allokerar. Annars kommer servicen att bara växa och växa och växa och till slut så har man ju slut på minne eller andra resurser (GDI objekt t ex)

Om du allokerat minne på heapen för din pekare bör du självfallet avallokera detsamma.

PeW skrev:

Om du allokerat minne på heapen för din pekare bör du självfallet avallokera detsamma.

Bra forumlering, PeW. Det finns inget som heter "deleta pekare", utan man deallokerar minnet en pekare pekar på. Det viktiga är att se till att matcha de new/delete man gör. Man kan ha 100 pekare som pekar på samma minnesyta och det är isåfall dåligt att göra delete av dessa.

Eftersom frågan löd om man måste så är det väl så att win32 frigör minnet när ett program avslutas. Men följ alltid Pews råd ändå.

FEL FEL FEL! Windows städar inte upp efter sig... däremot de flesta, om inte alla linux distrar, städar efter sig. Men!!! Tro inte att windows gör det... Vet iofs inte om XP gör det men 95, 98, NT, ME och 2K gör det inte!

Man ska alltid själv städa upp efter sig. Att lita på att OS:et gör det är alltid en risk och dålig programmering. Spelar ingen roll om os:et heter Windows eller Linux ;)

fnolis
Jag tror du har FEL FEL FEL ;)

*He* tro på... prova själv.... jag vet inte hur många gånger jag har dödat en NT och det är med olika servicepack också...

Learn by doing, trial and error...

fnolis skrev:

FEL FEL FEL! Windows städar inte upp efter sig... däremot de flesta, om inte alla linux distrar, städar efter sig. Men!!! Tro inte att windows gör det... Vet iofs inte om XP gör det men 95, 98, NT, ME och 2K gör det inte!

Skitsnack. Kan du visa ett reproducerbart exempel som påvisar vad du menar med att "Windows städar inte upp efter sig"?

Windows städar alltid upp efter sig. Detta gäller även Windows 95 och definitivt Windows NT.

Windows städar alltid upp efter sig. Detta gäller även Windows 95 och definitivt Windows NT.

Inte alltid och det är inte säkert att det görs på rätt sätt bara för att en process terminerar.

Inte alltid och det är inte säkert att det görs på rätt sätt bara för att en process terminerar.

Vilka andra resurser än t ex öppnade filer skulle bli kvar då processen går ur scope ? Minne som allokerats kommer att gå tillbaks till systemet.

Vilka andra resurser än t ex öppnade filer skulle bli kvar då processen går ur scope ? Minne som allokerats kommer att gå tillbaks till systemet

Visst, eftersom minnet tillhört processen. Men som du nämnde - vad händer med resurser som avsatts?

Visst, eftersom minnet tillhört processen. Men som du nämnde - vad händer med resurser som avsatts?

Det enda jag märkt är att filer kan lämnas öppna då processen går ur scope utan att man stängt dom innan. Annars vet jag inte vilka resurser du tänker på.

Developer kanske kan svara på vad som händer om man som lägger upp ett COM-objekt i ROT:en och sedan går man ur scope. Ligger objektet kvar där eller försvinner det då "skaparen' går ur scope och det inte är någonannan som håller en refferens till objektet ?

.. the system guarantees that all allocated memory is freed, all opened files are closed, all kernel objects have their usage counts decremented, and all User or GDI objects are freed regardless of how the process terminates.

Källa: Jeffrey Richter: Advanced Windows, Third Edition.

Sen är ju detta naturligtvis en beskrivning av ett normalfungerande välmående Windows. En gammal instabil 95:a eller 98:a precis efter en "it-may-be-possible-to-continue"-blåskärm kan ju eventuellt uppföra sig annorlunda ..

Beatbox skrev:

Det enda jag märkt är att filer kan lämnas öppna då processen går ur scope utan att man stängt dom innan. Annars vet jag inte vilka resurser du tänker på.

Det finns egentligen inget som heter "processen går ur scope", utan mer "när processen avslutas". Om en process har en fil öppen när den avslutas, kommer filen att stängas på ett kontrollerat sätt. Men om man skrivit data till filen, finns ingen garanti på att det datat verkligen sparats, eftersom OS:et buffrar skrivningar av prestandaskäl. Man måste därför se till att stänga filer själv. Det uppstår i vilket fall inga "resursläckor".

När man använder en HANDLE (till exempelvis en fil) från sin applikation (som snurrar i usermode), lagrar operativsystemet en motsvarande datastruktur som innehåller nödvändig information om filen. Det är ett skydd så att ett program inte ska kunna manipulera operativsystemets interna strukturer.

Oavsett hur en process avslutas, kommer alla spår av processen försvinna. Även om en process dör på ett "onaturligt" sätt, kommer en total uppstädning att göras. Både beträffande minne och resurser (dvs kernel-objekt).

Operativsystemet sköter detta genom att (för varje process) hålla en tabell över öppna kernel-objekt (filer, events, trådar etc.). När processen avslutas går OS:et igenom den tabellen och städar upp allt i tabellen. I och med att man kan ha flera referenser (HANDLEs) till ett och samma kernel-objekt (från en eller flera processer), måste objekten referensräknas. Först när ett objekt inte längre har någon process som använder det, tas resursen bort från kärnan.

Det finns en mycket bra bok som detaljerat beskriver detta och författarna har även skrivt många bra artiklar.

Beatbox skrev:

Developer kanske kan svara på vad som händer om man som lägger upp ett COM-objekt i ROT:en och sedan går man ur scope. Ligger objektet kvar där eller försvinner det då "skaparen' går ur scope och det inte är någonannan som håller en refferens till objektet ?

jag vet inte hur ROT hanterar när en process dör och inte har avregistrerat allt i ROT. Själva objekten försvinner ju i och med att processen dör, men jag vet inte hur ROT bestämmer när den ska släppa proxyn.

niko skrev:

En gammal instabil 95:a eller 98:a precis efter en "it-may-be-possible-to-continue"-blåskärm kan ju eventuellt uppföra sig annorlunda ..

Stora problemet med 95/98 är att system-dll:erna använder delat minne, så om en process pajar minnet, är det inte bara för sin egen process. I NT-baserade plattformar kan det inte hända.

:)

Nej, jag vet. Men eftersom den något luddiga frågan var huruvida Windows i alla situationer förmår städa efter sig (vad det nu exakt betyder?), så innefattas även 95/98/Me.

Beatbox & niko ->
GDI objekt som inte avslutats på rätt sätt har iaf fått min XP att krascha...