---

Nu har jeg ikke programmeret så meget i c, så lige for at være sikker på at
jeg har forstået det rigtigt mht pointere.

int *a;
a = (int *) malloc(40*sizeof(int));

Så er a nu et "array" med plads til 40 int?

Det skal være
free(a)
fx. free(a+1) er forkert? Dvs. man skal bruge den præcist pointer man fik
tilbage ved malloc ikke bare en der ligger et sted i det område man fik?

int *asdf() {}

betyder at asdf returnere en pointer til en int?

Ps. jeg sidder på en Linux maskine, men det burde vel ikke betyde noget.

--
Jesper

---

Jesper FA <news@skydiver.dk> writes:

> Nu har jeg ikke programmeret så meget i c, så lige for at være sikker på at
> jeg har forstået det rigtigt mht pointere.
>
> int *a;
> a = (int *) malloc(40*sizeof(int));
>
> Så er a nu et "array" med plads til 40 int?

Ja det har du helt ret i.

> Det skal være
> free(a)
> fx. free(a+1) er forkert? Dvs. man skal bruge den præcist pointer man fik
> tilbage ved malloc ikke bare en der ligger et sted i det område man fik?

Det er meget vigtigt at den punter, du bruger free, er den du får fra
malloc.

> int *asdf() {}
>
> betyder at asdf returnere en pointer til en int?

Ja, husk at allokere plads til den f.eks:
return (int *) malloc(40*sizeof(int));)
og at den skal free's igen.


> Ps. jeg sidder på en Linux maskine, men det burde vel ikke betyde noget.

nej det gør det ikke.

--
Mvh
Rasmus Meldgaard
rasmusm@diku.dk

---

Rasmus Meldgaard wrote:

>> int *a;
>> a = (int *) malloc(40*sizeof(int));
>>
>> Så er a nu et "array" med plads til 40 int?
>
> Ja det har du helt ret i.

Fint. Jeg synes nemmeligt ikke rigtigt jeg kunne kontrollere om jeg nu
havde fået det eller det bare var noget andet tilfældigt data jeg tilgik.

Hvor stor er sådanne en pointer egentligt.. Jeg undre mig nemmeligt lidt
over at hvis jeg udskriver værdien af den, så er det altid den samme for
det samme program.
Sådanne en pointer er den abselut i hukommelsen eller er den relativ i
noget virtuelt noget?

>> Det skal være
>> free(a)
>> fx. free(a+1) er forkert? Dvs. man skal bruge den præcist pointer man fik
>> tilbage ved malloc ikke bare en der ligger et sted i det område man fik?
> Det er meget vigtigt at den punter, du bruger free, er den du får fra
> malloc.

OK. Det må man jo så huske at huske på.

>> int *asdf() {}
>>
>> betyder at asdf returnere en pointer til en int?
>
> Ja, husk at allokere plads til den f.eks:
> return (int *) malloc(40*sizeof(int));)
> og at den skal free's igen.

Hvor meget ryder OS'et normalt op efter et program når det terminere?
Bliver alloceret hukommelse få frigivet, eller er det tabt indtil genstart.

>> Ps. jeg sidder på en Linux maskine, men det burde vel ikke betyde noget.
> nej det gør det ikke.

Mht. ovenstående kunne det vel betyde noget.

--
Jesper

---

Den Fri, 09 Mar 2001 19:57:43 GMT skrev Jesper FA:
>Rasmus Meldgaard wrote:
>
>>> int *a;
>>> a = (int *) malloc(40*sizeof(int));
>>>
>>> Så er a nu et "array" med plads til 40 int?
>>
>> Ja det har du helt ret i.
>
>Fint. Jeg synes nemmeligt ikke rigtigt jeg kunne kontrollere om jeg nu
>havde fået det eller det bare var noget andet tilfældigt data jeg tilgik.
>
>Hvor stor er sådanne en pointer egentligt.. Jeg undre mig nemmeligt lidt
>over at hvis jeg udskriver værdien af den, så er det altid den samme for
>det samme program.

Du kan ikke gå ud fra at den er den samme, men den vil ofte være det
samme, indtil du ændrer i programmet, eller bruger en anden compiler (på
nogen systemer har det også betydning hvilke andre programmer der er
startet. Så gå ud fra at den er ukendt.

>Sådanne en pointer er den abselut i hukommelsen eller er den relativ i
>noget virtuelt noget?

Det afhænger af OS'et.

>>> Det skal være
>>> free(a)
>>> fx. free(a+1) er forkert? Dvs. man skal bruge den præcist pointer man fik
>>> tilbage ved malloc ikke bare en der ligger et sted i det område man fik?
>> Det er meget vigtigt at den punter, du bruger free, er den du får fra
>> malloc.
>
>OK. Det må man jo så huske at huske på.
>
>>> int *asdf() {}
>>>
>>> betyder at asdf returnere en pointer til en int?
>>
>> Ja, husk at allokere plads til den f.eks:
>> return (int *) malloc(40*sizeof(int));)
>> og at den skal free's igen.
>
>Hvor meget ryder OS'et normalt op efter et program når det terminere?
>
>Bliver alloceret hukommelse få frigivet, eller er det tabt indtil genstart.

Afhænger af OS'et. På Linux kan du gå ud fra at alt bliver ryddet op.
Under DOS/windows kan man nogengange få en opfattelse af at alt er
tabt indtil genstart.

Men gør det til en vane altid at deallokere hukommelse, og lukke filer.
Programmet bliver mere korrekt, du får mere øvelse i at programmere,
og der er mindre chance for at det ender med en blå skærm, den dag
du flytter dit program over på en windowsmaskine.

>>> Ps. jeg sidder på en Linux maskine, men det burde vel ikke betyde noget.
>> nej det gør det ikke.
>
>Mht. ovenstående kunne det vel betyde noget.

Ja, man kan tillade sig at gå ud fra at systemet virker.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: house.png

---

Jesper FA <news@skydiver.dk> writes:

> Hvor stor er sådanne en pointer egentligt.. Jeg undre mig nemmeligt lidt
> over at hvis jeg udskriver værdien af den, så er det altid den samme for
> det samme program.

Det man får fra malloc() er en pointer -- dvs. en adresse på et stykke
af det lager som processen har til rådighed. En pointer er altså ikke
andet end et tal. Du kan ikke regne med at værdien af en pointer
altid er den samme for det samme program, men det vil ofte være
tilfældet under Unix, for dér bliver hver proces bildt ind at den har
hele lageret til rådighed, så malloc() vil opføre sig ens hver gang.

> Sådanne en pointer er den abselut i hukommelsen eller er den relativ i
> noget virtuelt noget?

En pointer er bare en adresse, men der er ikke noget der forhindrer
operativsystemet i at bestemme sig for at lageret som en pointer i en
bestemt proces peger på, skal flyttes ud på disken. Hvis programmet
forsøger at læse eller skrive i hukommelsen som pointeren refererer,
bliver det læst ind i den fysiske hukommelse.

> Hvor meget ryder OS'et normalt op efter et program når det terminere?
> Bliver alloceret hukommelse få frigivet, eller er det tabt indtil genstart.

Unix-afarter, herunder Linux, rydder al hukommelsen op når processer
afsluttes, medmindre processerne har benyttet sig af shared memory
(som er en UNIX-feature og ikke en del af C-standarden). Jeg mener at
have set sædvanligvis upålidelige kilder på nettet påstå at nogle
versioner af Windows ikke rydder op efter processer, men jeg tror nu
ikke rigtig på dem.

---

In article <XAaq6.2575$lk1.65098@twister.sunsite.dk>, Jesper FA wrote:
>Rasmus Meldgaard wrote:
>
>
>Hvor stor er sådanne en pointer egentligt.. Jeg undre mig nemmeligt lidt
>over at hvis jeg udskriver værdien af den, så er det altid den samme for
>det samme program.

På en 386+ med et 32 bit operativsystem og en 32 bit compiler, er den
....trommehvirvel... 32 bit. I de fleste situationer vil pointere være den
samme størrelse som CPU arkitekturens. Når man skriver portabel software,
er det derfor vigtigt at bruge sizeof(type*) i stedet for 4, når man
allokerer hukommelse til pointere.

Man bør desuden så vidt muligt undgå at gemme pointere i integers, da man
ikke altid kan regne med at de har samme størrelse. På Intel arkitektur
med 32 bit integers passer det, men ofte er det galt.

>
>Hvor meget ryder OS'et normalt op efter et program når det terminere?
>Bliver alloceret hukommelse få frigivet, eller er det tabt indtil genstart.
>

Hårdnakkede rygter vil vide, at win9x/ME ikke kan rydde ordentligt op, så
den bliver langsommere for hver gang man kører et program, der ikke rydder
op på heapen. Et moderne OS burde rydde op. Som udgangspunkt går jeg
normalt efter at rydde alt op selv før terminering (medmindre det bare er
et lille eksperiment, jeg laver).

Torsten

---

Hej,

> Hårdnakkede rygter vil vide, at win9x/ME ikke kan rydde ordentligt op, så
> den bliver langsommere for hver gang man kører et program, der ikke rydder
> op på heapen.

Mon dog det gælder for malloc? Hvis man har et fornuftigt køretidsystem der
kører under et dårligt operativsystem vil det selvfølgelig sørge for at
frigive alt lager som det har allokeret af operativsystemet når programmet
afslutter. Desuden vil malloc vel normalt ikke lave en kald til
operativsystemet for hver gang den kaldes. I stedet vil data blive allokeret
i større blokke som det skulle være en smal sag for køretidssystemet om
nødvendigt at frigive eksplicit når programmet afsluttes.


Venlig Hilsen

Christian Worm

---

In article <98crpl$ote$1@news.inet.tele.dk>, Christian Worm Mortensen wrote:
>Hej,
>
>> Hårdnakkede rygter vil vide, at win9x/ME ikke kan rydde ordentligt op, så
>> den bliver langsommere for hver gang man kører et program, der ikke rydder
>> op på heapen.
>
>Mon dog det gælder for malloc? Hvis man har et fornuftigt køretidsystem der
>kører under et dårligt operativsystem vil det selvfølgelig sørge for at
>frigive alt lager som det har allokeret af operativsystemet når programmet
>afslutter.

Du har ret. Hvis man får kaldt termineringskoden for memory manageren,
skulle der ikke være et problem. Måske kan det (at hukommelse hænger i
windows) ske ved crash af programmer, eller i programmer, der bruger
LocalAlloc?

Torsten

---

* Jesper FA
> Rasmus Meldgaard wrote:
>
> >> int *a;
> >> a = (int *) malloc(40*sizeof(int));
> >>
> >> Så er a nu et "array" med plads til 40 int?
> >
> > Ja det har du helt ret i.
>
> Fint. Jeg synes nemmeligt ikke rigtigt jeg kunne kontrollere om jeg
> nu havde fået det eller det bare var noget andet tilfældigt data jeg
> tilgik.


Et par små tilføyelser:

En peker og en array i C er _egentlig_ 2 vesentlig forskjellige ting.
Alikevel, under noen omstendigheter regnes de som ekvivalente. Ikke
alle bøker er like flinke til å sette fokus på denne forskjellen, men
denne:

"Expert C Programming: Deep C Secrets"
Linden, Peter van der
ISBN: 0-131-77429-8
Publisher: SunSoft Press
Year: 1994

poengerer veldig godt en del finurlige ting.

Nå tilbake til hva a egentlig er: det er en _peker_. Ikke en array.
Men det objektet i hukommelsen som a peker på er 40 int'er som er
plassert i hukommelsen rett etter hverandre:


a 0 1 2 3 4 5 6 7 39
+-+ +--+--+--+--+--+--+--+--+- ... --+--+
|----------->| | | | | | | | | | |
+-+ +--+--+--+--+--+--+--+--+- ... --+--+


Noen foretrekker å kalle slike objekter for arrays. IMHO er dette
misvisende, da semantikken til slike objekter er forskjellig fra
arrays.

En annen liten ting: det er ofte fordelaktig å _ikke_ typecast'e
returverdien fra malloc:

int *a = malloc( 40 * sizeof *a );

Det er helt riktig at utrykket på venstre siden er av typen "int*"
mens det på høyre siden er av typen "void*", men typecast "void* ->
T*" skjer implisitt ved tilordning. Derimot, mangelen på eksplisitt
typecast får veldig mange kompilatorer til å advare om at man har
glemt å #include <stdlib.h>.


> Hvor stor er sådanne en pointer egentligt..


sizeof( int* )? Nei, det vil variere fra en maskin til en annen. Det
er typisk noe man ikke skal bekymre seg om (ej heller stole på at
denne har en bestemt verdi)


> Jeg undre mig nemmeligt lidt over at hvis jeg udskriver værdien af
> den, så er det altid den samme for det samme program. Sådanne en
> pointer er den abselut i hukommelsen eller er den relativ i noget
> virtuelt noget?


I tillegg til det Kent Friis har skrevet.

_Moderne_ OS vil sjelden la et program til en vanlig bruker ha noe
forståelse for hvordan den fysiske hukommelsen ser ut. Den store
fordelen med virtuelt hukommelse er at hvert program ser et flatt
adresserom fra 0 til N minneceller (_veldig_ ofte er den minste
adresserbare enheten 8 bits stor (igjen, ofte (og feilaktig) omtalt
som en byte)). Du sitter sikkert på Intel Linux, og da innbiller jeg
meg at adresserommet er fra 0 til 4,294,967,295. Og programmet ditt
opererer med virtuelt minne. I tillegg til boken til van der Linden
(som omtaler hvordan et C program ser ut i et Unix (Solaris) miljø),
kan du ta en titt på denne:

"Computer Achitecture: A Quantitative Approach", 2nd ed
Hennessy, John L and Patterson, David A.
ISBN: 1-558-60372-7
Publisher: Morgan Kaufmann
Year: 1995

Den inneholder bl.a. en beskrivelse av hvordan virtuelt hukommelse ser
ut "innvendig".


> >> Det skal være
> >> free(a)
> >> fx. free(a+1) er forkert? Dvs. man skal bruge den præcist pointer man fik
> >> tilbage ved malloc ikke bare en der ligger et sted i det område
> >> man fik?


Det er minst 2 gode grunner til det:

a. standarden _krever_ det (man kan free()'e kun det som man fikk fra
malloc()).

b. Noen implementasjoner realiserer hele greia ved å skrive størrelsen
på det allokerte området rett før 1. (altså, null'te) element. Gir man
feil element til free, kommer man muligens til å frigjør feil antall
elementer.


> >> int *asdf() {}
> >>
> >> betyder at asdf returnere en pointer til en int?
> >
> > Ja, husk at allokere plads til den f.eks:
> > return (int *) malloc(40*sizeof(int));)
> > og at den skal free's igen.


Det er ikke nødvendig -- den pekeren som asdf returnerer kan være
global eller lokal og static. Slik kan man implementere strerror (bare
for å ta et eksempel).


> Hvor meget ryder OS'et normalt op efter et program når det
> terminere? Bliver alloceret hukommelse få frigivet, eller er det
> tabt indtil genstart.


Standarden sier at oppførselen ikke er definert, dersom man ikke
frigjør eksplisitt det som er blitt malloc()'et. Det er en god vane å
gjøre det, til tross for at ethvert OS med respekt for seg selv vil
gjenbruke de (private) ressursene som en prosess har allokert etter at
prosessen er terminert.

[snip]





ivr, 22
--
Besides, meat tends to run away when possible, or fights. Either
response presents behavioral challenges too complex for any existing
robot.
      -- Stuart Wilkinson, inventor of the "gastrobot"