Hamnar de lokala variablerna i en rekursiv funktion på heapen eller stacken? Kompilatorn kan ju inte veta i förväg hur många gånger den rekursiva funktinonen går in i sig själv.

På stacken.

okej så stacken kan även hantera sådant som är dynamsikt.

Det är just det den gör. Varje gång ett funktionsanrop sker, används stacken. Först sparas anroparen argumenten och returadressen. Sedan sker hoppet till funktionen, vilken i sin tur använder utrymme på stacken för lokala variabler. När funktionen avslutas, återställs utrymmet i omvänd ordning.

En funktion får (åtminstone bör) dock inte returnera adresser till saker den själv lagt på stacken, eftersom det kan komma att skrivas över av den anropande funktionen. Då använder man heapen i stället.

En annan viktig skillnad mellan stacken och heapen är att stacken brukar ha en mer begränsad storlek än heapen har. I princip skulle man kunna bygga upp t.ex. ett träd på stacken, men det finns många problem med det.

Okej... tack för förklaringen.. blev lite fundersam på hur det fungerar då man hört att dynamisk data sparas på heapen medans statisk data sparas på stacken. En rekursiv funktion blir liksom ett mellanläge men det låter verkligen logiskt det du säger nu när man tänker efter.

Det jag skulle kalla statisk data lagras varken på stacken eller i heapen utan i någon annan area.

Det jag kallar statisk data är:
* konstanta strängar, t.ex. i cout << "Detta är en konstant sträng" << endl;
* globala variabler
* statiska lokala variabler
(ev. något mer)

Statiskt var helt fel ordval av mig. Blev första tanken som motsats till dynamisk data. Men var lagras i så fall globala variabler och sådant om de varken lagras på stack eller heap? Att dynamiska variabler sparas på heapen har jag vetat länge och även att lokala variabler som inte är dynamisk sparas på stacken. Att det finns ytterligare ställen på minnet där övrig data sparas viste jag inte. Var sparas i så fall dynamiska globala variabler?

För ett enkelt program skulle globala variabler och konstanter kunna lagras tillsammans med den exekverbara koden, men vanligtvis delar man upp all data i olika sektioner vilka laddas in i något olika delar av minnet:
* kod
* initierad global data
* oinitierad global data
* konstant data
* stack
För de olika sektionerna skulle man kunna sätta olika åtkomsträttigheter, t.ex. behöver koden förstås vara exekverbar men oftast inte vara skrivbar, medan man vill att stacken skall vara läs- och skrivbar, men inte exekverbar.

Heapen brukar däremot inte reserveras till en viss storlek direkt, utan utökas vid behov genom att minneshanteringsfunktionerna (malloc/free i C, new/delete i C++) begär mer utrymme av operativsystemet.

Det finns alltså Heap, Stack, Global varabler m.m. ,registret och någon minnesplats för själva programmets exekverbara kod (eller vad man ska kalla det) där data sparas i minnet.

Okej. Nu har jag fått en hel del förklarat för mig om hur minnet hanteras. Tack för det.
Skrev ovanstående inlägg innan jag läst det du postat.

vist är det så att new egentligen kör malloc och delete kör free och kanke även lite annan kod. Man kan väll överlagra new och delete och skapa sin egen hantering av minnet.

Japp, det finns många ställen...

<b>>vist är det så att new egentligen kör malloc och delete kör free och kanke även lite annan kod. Man kan väll överlagra new och delete och skapa sin egen hantering av minnet.</b>
Nja, inte nödvändigtvis. new och delete är inbyggda operatorer och kan få bättre effektivitet etc. om de är byggda från grunden. I princip använder de dock samma grej.

Sen är det korrekt att man kan överlagra new och delete, men som "medelanvändare" är det ytterst sällan man har någon nytta av det. Man får ha rätt extrema krav om man ska behöva börja med det, och minnesläckor är svåra att undvika helt.

Så som jag uppfattat det så kan överlagring av new och delete vara rätt praktiskt om man jobbar med större projekt just för att undvika minnesläckage då man i new kan registrera exakt hur mycket minne som är allokerat via new och sedan i delete kolla så att lika mycket är avallokerat. Sedan kan detta vara användbart för att slippa fragmentering på heapen genom att hantera var olika data hamnar på heapen. Detta är självklart en överkurs och endast användbart vid väldigt extrema situationer då man behöver utnyttja max av datorn.

>Så som jag uppfattat det så kan överlagring av new och delete vara rätt praktiskt om man jobbar med större projekt
>just för att undvika minnesläckage

Det blir ett ganska jobigt sätt att undvika minnesläckage om man skall definiera operatorerna new och delete för varje klass man använder. Finns många bättre sätt att göra det:
1. Använd någon smartptr så att minnet automatiskt återlämnas när man är klar.
2. I VS kan man göra "#define new DEBUG_NEW" så får man en automatisk koll om allt minne är avallokerat när programmet avslutas.

Överlagring av new & delete brukar används istället för att undvika en massa allokeringar av små objekt. Man kan då ha en new funktion som allokerar X objekt på en gång och sedan internt håller ordning på vilka som är lediga.

<b>>Överlagring av new & delete brukar används istället för att undvika en massa allokeringar av små objekt. Man kan då ha en new funktion som allokerar X objekt på en gång och sedan internt håller ordning på vilka som är lediga.</b>
Och i sammanhanget är det nog också lämpligt att säga att standardbiblioteket inte sällan har effektiva metoder för att själv lista ut hur mycket minne som behövs, och att det också finns inbyggda funktioner för att allokera minne om man vet hur många objekt man har för ex. vector.