---

Hej.
Hvornår er det nødvendigt at bruge New ell Malloc.
Når man ikke kender størrelsen af pladsforbrug bruges det,
men bruges det ved f.eks også 10 byte forbrug, eller er det over en vis
størrelse det først bruges, i de bøger jeg har kigget i skrives der hvordan
de bruges, men ikke hvornår.

--
Hilsen
Michael Olsen

---

"Michael Olsen" <michael@nospam.dkfritidmotorcykel.dk> wrote in message
news:45fae1ab$0$90274$14726298@news.sunsite.dk...
> Hej.
> Hvornår er det nødvendigt at bruge New ell Malloc.

Det skrives med småt: "new" og "malloc".

> Når man ikke kender størrelsen af pladsforbrug bruges det,
> men bruges det ved f.eks også 10 byte forbrug, eller er det over en vis
> størrelse det først bruges, i de bøger jeg har kigget i skrives der
> hvordan
> de bruges, men ikke hvornår.

Det bruges typisk når man ikke på forhånd ved hvor meget plads der skal
bruges.
Det bruges når levetiden af objektet ikke følger eksekveringsflowet.
Det bruges hvis man skal bruge _meget_ plads til en lokal variabel, idet
pladsen typisk ellers allokeres på kaldestakken der har begrænset størrelse.

Når det er sagt, gør man sig selv en tjeneste ved ikke at benytte det så
hyppigt i C++.
Ofte er man bedre tjent med at bruge klasser, der tager sig af hukommelses
styringen, så som "std::vector" og "std::string".

--
Venlig hilsen

Mogens Hansen

---

> Når man ikke kender størrelsen af pladsforbrug bruges det,
> men bruges det ved f.eks også 10 byte forbrug

Nu kender jeg ikke helt dit niveau , så jeg plabrer bare løs !
Here we go:

Stak:
Hvis du bare erklærerer en autovariabel i funktionen, ender den på stakken.
Faren ved dette er, at hvis alle funktioner gør dette, kan du risikere at
din stak løber over, og dermed har du katastrofen. Det kan være svært at
påvirke programmet sådan at du kan måle max stak forbruget. Dermed bliver
man nødt til at sætte den x % større end det max målte stakforbrug.
Hvis du gerne vil returnere en pointer til nogle data til en anden funktion,
så DUER DENNE METODE IKKE, idet stakken øjeblikket senere vil være
overskrevet.

Heap
Hvis du new'er / malloc'er, har du udfordringen med at kalde new og delete
præist lige mange gange , ellers har du en memory leak. Det lyder lettere
end det er, hvis programmet bliver rigtig stort og komplekst.
Desuden har du udfordringen med at få testet at du håndterer at new/malloc
svarer failed alle mulige steder i koden. Det lyder også lettere end det er
i praksis.
Jeg har hørt om folk der har lavet en wrapper til malloc funktionen, som
svarer failed i 1% af tilfældene på tilfældige tidspunkter, bare for at
teste om ens program kan finde på at crashe på den ondeste måde, eller bare
gå i en logisk baglås.

Statisk
Statiske buffere er også en muliged. Hvis du har et modul der altid skal
bruge to buffere til diverse formål gennem hele programmets levetid, kan du
erklære den på top niveau i c filen. Dermed vil de jo bare optage hukommelse
under hele programmets forløb.
Det svarer næsten til at malloce bufferne i init rutien og free dem igen når
programmet lukkes.
På en embedded platform skal man dog huske, at malloc og free er funktioner
der optager kodeplads, og man skal reservere et helt område til Heap'en, så
der kommer en del overhead. Så i dette tilfælde kan man vælge bare at bruge
den statiske allokering. Så får man også at vide på linkningstidspunktet om
man har hukommelse nok.

Konkret:
Hvis du skal bruge en midlertidig buffer på 10 bytes, allokerer du den bare
som autovariabel.
Hvis dette er noget data som du skal sende videre i systemet kan du vælge at
malloc'e bufferen, og lade det være op til andre dele af systemet at free'e
den.
Grænsen er vel flydende, på en pc er det ok med lidt større buffere, på en
embedded platform skal man passe på ikke at bruge 100 bytes af stakken for
mange gange, hvis man kun har en stak på 256 bytes!

Hvis du skal bruge store buffere, er malloc god stil.
Jeg synes engang at jeg prøvede at bare skrive char myBuf[10000000] (10
meg). Det virkede sq ikke rigtigt , før jeg pænt bad windows om en sådan
buffer. Fandt aldrig helt ud af hvor grænsen er.

(Godt med nogle posts i gruppen igen)

tpt

---

> Hvis du skal bruge en midlertidig buffer på 10 bytes, allokerer du den
> bare som autovariabel.

Disse 10 bytes, hvornår bliver de frigivet igen, er det når funktionen
de er allokeret i afsluttes, eller er det operativ systemet der rydder op
nå der er mangel på plads.


--
Hilsen
Michael Olsen

---

"Michael Olsen" <michael@nospam.dkfritidmotorcykel.dk> wrote in message
news:46081c65$0$90264$14726298@news.sunsite.dk...
>> Hvis du skal bruge en midlertidig buffer på 10 bytes, allokerer du den
>> bare som autovariabel.
>
> Disse 10 bytes, hvornår bliver de frigivet igen, er det når funktionen
> de er allokeret i afsluttes,

Ja.
Det typiske er at automatiske (lokale) variable bliver allokeret på CPU'en
kaldestak. Dermed bliver hukommelsen frigivet når funktionen afsluttes.
Hvis man allokerer et objekt med constructor og destructor, vil
constructoren blive eksekveret når variablen begynder at eksistere (kommer
ind i scope) og destructoren bliver eksekveret når variablen går ud af
scope.
F.eks.
void foo()
{
bar b1; // bar default constuctor for b1 executes

{
bar b2; // bar default constructor for b2 executes
} // bar destrcutor for b2 executes

bar b3; // default constructor for b3 executes

} // bar destructor for b1 and b3 executes

Det er dog ikke et krav at det fungerer sådan - men det er et krav at det
opfører sig sådan.

Prøv at lav et lille program, der allokerer et objekt, som har en
constructor og destructor der skriver lidt ud, og kør det med en debugger.

> eller er det operativ systemet der rydder op
> nå der er mangel på plads.

Nej - slet ikke.

--
Venlig hilsen

Mogens Hansen

---

>> eller er det operativ systemet der rydder op
>> nå der er mangel på plads.
>
> Nej - slet ikke.
>

Det du foreslår er jo i realiteten en garbage collector.
Det er ikke en del af standard C/C++, men du kan komme ret tæt på med Boost
libet (reference counting) .
http://www.boost.org/libs/smart_ptr/smart_ptr.htm

Svjv ryder den op i det øjeblik at der ikke er flere referencer til
objektet, istedet for Java' og C#'s ide med at gøre det når der er mangel på
plads. Det gør eksekveringstiden deterministisk.

tpt

---

Den Tue, 27 Mar 2007 01:28:39 +0200 skrev Troels Thomsen:
>
>>> eller er det operativ systemet der rydder op
>>> nå der er mangel på plads.
>>
>> Nej - slet ikke.
>>
>
> Det du foreslår er jo i realiteten en garbage collector.

Nej, det er sådan stack'en fungerer.

> Det er ikke en del af standard C/C++, men du kan komme ret tæt på med Boost
> libet (reference counting) .
> http://www.boost.org/libs/smart_ptr/smart_ptr.htm

Garbage collection har ikke noget med stack'en at gøre.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Prøv nu lige at læs indlægene igen med denne optik:
Mogens svarer noget, som er helt enig i, og så tilføjer jeg et par ord til
MO.

tpt

---

Den Thu, 29 Mar 2007 23:03:59 +0200 skrev Troels Thomsen:
>
> Prøv nu lige at læs indlægene igen med denne optik:
> Mogens svarer noget, som er helt enig i, og så tilføjer jeg et par ord til
> MO.

Ja, tilføjer noget fuldstændig forkert.

Der var intet i det Mogens skrev der havde noget med en garbage-
collector at gøre.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

>
> Der var intet i det Mogens skrev der havde noget med en garbage-
> collector at gøre.
>

Du _vil_ ikke forstå ?


Som jeg skrev, var intet i mit indlæg møntet på Mogens. Jeg skulle måske
have trykket reply på Mikaels post istedet. Så havde det set således ud:

>>> eller er det operativ systemet der rydder op
>>> nå der er mangel på plads.
>
> Det du foreslår, er jo i realiteten en garbage collector.

Det var MO's formulering " rydder op når der er mangel på plads." der
mindede mig om en garbage collector.

Jeg tror vi er helt enige om hvordan stakken virker.


tpt

---

"Troels Thomsen" <nej tak ...> wrote in message
news:460e7487$0$52199$edfadb0f@dread11.news.tele.dk...

[8<8<8<]
> Det var MO's formulering " rydder op når der er mangel på plads." der
> mindede mig om en garbage collector.

Sådan opfattede jeg det også

--
Venlig hilsen

Mogens Hansen