---

Hej gruppe.

MS Visual.NET C/C++ tillader mig ikke at definere et array hvis størrelse
(dvs. antallet af elementer i array'et) er bestemt ved runtime /
compile-time, fx når en funktion har udregnet den ønskede størrelse.
Compilerens fejlbesked står lige efter den lille stump kode.

int calculateSize() {
...
return variable;
}

someFunction() {
const int size = calculateSize(...);

int array[size];

// initialisering...
for (int i = 0; i < size; i++)
array[i] = 0;
}


error C2057: expected constant expression
error C2466: cannot allocate an array of constant size 0
error C2133: 'array' : unknown size

Mit spørgsmål lyder på hvordan jeg kan løse problemet? Vil følgende løse
det?

int *ptrArray = new int[];


--
Mvh. / Best regards,
Jack L.,
Copenhagen, EU

---

Jack L. skrev:

> MS Visual.NET C/C++ tillader mig ikke at definere et array hvis størrelse
> (dvs. antallet af elementer i array'et) er bestemt ved runtime /
> compile-time, fx når en funktion har udregnet den ønskede størrelse.

Det er C der ikke tillader det. Du kan bruge malloc() der
tildeler så meget plads som parameteren angiver.

> int array[size];

Erstat med:

   int *array;

i erklæringen og

   array=malloc(size);

i 'arbejdsdelen'. Når du bruger malloc(), skal du selv frigive
pladsen igen (med free(array)) medmindre den skal bruges hele
programmet igennem (hvorefter den frigives automatisk).

Hvis du laver en ny tildeling til array uden at frigive først,
får du hukommelsesspild.

Hukommelse tildelt med malloc() i en funktion frigives *ikke* når
man forlader funktionen.

Princippet kaldes "dynamisk tildeling".

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Den Sun, 9 Apr 2006 08:45:46 +0200 skrev Bertel Lund Hansen:
> Jack L. skrev:
>
>> MS Visual.NET C/C++ tillader mig ikke at definere et array hvis størrelse
>> (dvs. antallet af elementer i array'et) er bestemt ved runtime /
>> compile-time, fx når en funktion har udregnet den ønskede størrelse.
>
> Det er C der ikke tillader det.

Er du sikker på det? Jeg har mange steder kode som:

char s[27+strlen(user)];
char replymsg[strlen(user)+18];

Men det er måske en gcc-extension?

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis skrev:

>> Det er C der ikke tillader det.

> Er du sikker på det?

Belært af en nylig erfaring skulle jeg nok have udtalt mig mindre
skråsikkert. Jeg har K&R som reference og Borlands gratis C++ v.
5.5 som program. Begge er ... øh, ikke just opdaterede.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Kent Friis wrote:
> Den Sun, 9 Apr 2006 08:45:46 +0200 skrev Bertel Lund Hansen:
>>Jack L. skrev:
>>>MS Visual.NET C/C++ tillader mig ikke at definere et array hvis størrelse
>>>(dvs. antallet af elementer i array'et) er bestemt ved runtime /
>>>compile-time, fx når en funktion har udregnet den ønskede størrelse.
>>
>>Det er C der ikke tillader det.
>
>
> Er du sikker på det? Jeg har mange steder kode som:
>
> char s[27+strlen(user)];
> char replymsg[strlen(user)+18];
>
> Men det er måske en gcc-extension?

Nej, det er standard C (C99). Tidligere (C89) var det ikke standard. Og
det er ikke C++.

mvh. Anders

---

Den Sun, 09 Apr 2006 14:18:55 +0200 skrev Anders J. Munch:
> Kent Friis wrote:
>> Den Sun, 9 Apr 2006 08:45:46 +0200 skrev Bertel Lund Hansen:
>>>Jack L. skrev:
>>>>MS Visual.NET C/C++ tillader mig ikke at definere et array hvis størrelse
>>>>(dvs. antallet af elementer i array'et) er bestemt ved runtime /
>>>>compile-time, fx når en funktion har udregnet den ønskede størrelse.
>>>
>>>Det er C der ikke tillader det.
>>
>>
>> Er du sikker på det? Jeg har mange steder kode som:
>>
>> char s[27+strlen(user)];
>> char replymsg[strlen(user)+18];
>>
>> Men det er måske en gcc-extension?
>
> Nej, det er standard C (C99). Tidligere (C89) var det ikke standard. Og
> det er ikke C++.

Ok, så var det altså en gcc-extension da jeg skrev koden, for de skulle
stå i starten af en {}-blok - og det er ikke længere et krav i C99.

For dem der ikke er nået til C99 endnu, skulle man måske lige nævne
alloca() - så slipper man for at holde styr på free, da den allokerede
plads bliver frigivet når blokken slutter, ligesom normale variable.
C-lærebøger IMHO burde fokusere meget mere på alloca() frem for at bruge
malloc altid, det kan spare en masse memory leaks.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Sun, 09 Apr 2006 14:18:55 +0200 skrev Anders J. Munch:
>
>>Kent Friis wrote:
>>
>>>Den Sun, 9 Apr 2006 08:45:46 +0200 skrev Bertel Lund Hansen:
>>>
>>>>Jack L. skrev:
>>>>
>>>>>MS Visual.NET C/C++ tillader mig ikke at definere et array hvis størrelse
>>>>>(dvs. antallet af elementer i array'et) er bestemt ved runtime /
>>>>>compile-time, fx når en funktion har udregnet den ønskede størrelse.
>>>>
>>>>Det er C der ikke tillader det.
>>>
>>>
>>>Er du sikker på det? Jeg har mange steder kode som:
>>>
>>>char s[27+strlen(user)];
>>>char replymsg[strlen(user)+18];
>>>
>>>Men det er måske en gcc-extension?
>>
>>Nej, det er standard C (C99). Tidligere (C89) var det ikke standard. Og
>>det er ikke C++.
>
>
> Ok, så var det altså en gcc-extension da jeg skrev koden, for de skulle
> stå i starten af en {}-blok - og det er ikke længere et krav i C99.
>
> For dem der ikke er nået til C99 endnu, skulle man måske lige nævne
> alloca() - så slipper man for at holde styr på free, da den allokerede
> plads bliver frigivet når blokken slutter, ligesom normale variable.

Hvad mener du med "når blokken slutter"?


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Sun, 09 Apr 2006 15:35:13 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
>> Den Sun, 09 Apr 2006 14:18:55 +0200 skrev Anders J. Munch:
>>
>>>Kent Friis wrote:
>>>
>>>>Den Sun, 9 Apr 2006 08:45:46 +0200 skrev Bertel Lund Hansen:
>>>>
>>>>>Jack L. skrev:
>>>>>
>>>>>>MS Visual.NET C/C++ tillader mig ikke at definere et array hvis størrelse
>>>>>>(dvs. antallet af elementer i array'et) er bestemt ved runtime /
>>>>>>compile-time, fx når en funktion har udregnet den ønskede størrelse.
>>>>>
>>>>>Det er C der ikke tillader det.
>>>>
>>>>
>>>>Er du sikker på det? Jeg har mange steder kode som:
>>>>
>>>>char s[27+strlen(user)];
>>>>char replymsg[strlen(user)+18];
>>>>
>>>>Men det er måske en gcc-extension?
>>>
>>>Nej, det er standard C (C99). Tidligere (C89) var det ikke standard. Og
>>>det er ikke C++.
>>
>>
>> Ok, så var det altså en gcc-extension da jeg skrev koden, for de skulle
>> stå i starten af en {}-blok - og det er ikke længere et krav i C99.
>>
>> For dem der ikke er nået til C99 endnu, skulle man måske lige nævne
>> alloca() - så slipper man for at holde styr på free, da den allokerede
>> plads bliver frigivet når blokken slutter, ligesom normale variable.
>
> Hvad mener du med "når blokken slutter"?

{ /* Her starter blokken */
char * x = alloca(256);
   
   strcpy(x,"hej");
   printf("%s\n",x);
} /* Her slutter blokken */

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
-snip-

>>>For dem der ikke er nået til C99 endnu, skulle man måske lige nævne
>>>alloca() - så slipper man for at holde styr på free, da den allokerede
>>>plads bliver frigivet når blokken slutter, ligesom normale variable.
>>
>>Hvad mener du med "når blokken slutter"?
>
>
> { /* Her starter blokken */
> char * x = alloca(256);
>    
>    strcpy(x,"hej");
>    printf("%s\n",x);
> } /* Her slutter blokken */

Altså jeg forstår stadigvæk ikke helt eksemplet, men jeg heller ikke
C-ekspert. Du reserverer plads til 256 bytes og bruger kun under 10.

Såvidt jeg kan se her: http://tigcc.ticalc.org/doc/alloc.html#alloca så
er den faktiske forskel at strengen kopieres ind på stakken istedet for
i heap'en (eller hvad det hedder). Og det kræver at du har har en
funktion at kalde... Det burde du nok lige have gjort opmærksom på, hvis
jeg forstår tingene korrekt. Det fremgår ikke så tydeligt af dit
eksempel selvom du har omklandret koden med brackets.

Iøvrigt kan jeg ikke se at det skulle være noget problem at holde styr
på pointers'ene til brug for free(), så jeg forstår da udmærket at
malloc gennemgås i mange tekstbøger men ikke alloca. Der står jo også:
"alloca is a function which is not included in the ANSI C standard". Så
man kan ligeså godt lære malloc() som det første, da den ikke er til at
komme udenom.

Derudover tror jeg ikke det er en god ide at lægge mange kilobytes eller
megabytes data på stakken - jeg er som sagt ikke ekspert, men det er mit
indtryk at det er stakken ikke beregnet til... Ihvertfald ifb. med dos
..com-filer mener jeg at stakken har en naturlig begrænsning på x antal
kbytes. Hvordan det er med windows .exe-filer og andre program-filer ved
jeg så ikke.


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Mon, 10 Apr 2006 00:19:15 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
> -snip-
>
>>>>For dem der ikke er nået til C99 endnu, skulle man måske lige nævne
>>>>alloca() - så slipper man for at holde styr på free, da den allokerede
>>>>plads bliver frigivet når blokken slutter, ligesom normale variable.
>>>
>>>Hvad mener du med "når blokken slutter"?
>>
>>
>> { /* Her starter blokken */
>> char * x = alloca(256);
>>    
>>    strcpy(x,"hej");
>>    printf("%s\n",x);
>> } /* Her slutter blokken */
>
> Altså jeg forstår stadigvæk ikke helt eksemplet, men jeg heller ikke
> C-ekspert. Du reserverer plads til 256 bytes og bruger kun under 10.

Jaja, det var jo et eksempel for at vise hvor en blok slutter,
ikke et eksempel på optimering af buffer-størrelser.

> Såvidt jeg kan se her: http://tigcc.ticalc.org/doc/alloc.html#alloca så
> er den faktiske forskel at strengen kopieres ind på stakken istedet for
> i heap'en (eller hvad det hedder).

Korrekt.

> Og det kræver at du har har en
> funktion at kalde...

Ikke forstået. Al C-kode ligger i funktioner, main() er også en
funktion.

> Det burde du nok lige have gjort opmærksom på, hvis
> jeg forstår tingene korrekt. Det fremgår ikke så tydeligt af dit
> eksempel selvom du har omklandret koden med brackets.

Blokken kunne også være fx en if-blok eller en while-blok.

> Iøvrigt kan jeg ikke se at det skulle være noget problem at holde styr
> på pointers'ene til brug for free(),

Mange programmer har memory-leaks. Der findes endda programmer der
kan finde memory-leaks i andre programmer. Og de er ikke beregnet
specielt til begyndere, selv folk der har programmeret i mange år
glemmer en gang imellem en free(), så programmet lige så stille
leaker memory.

Det er nemt nok at holde styr på i små programmer. Men når man
pludselig begynder at have adskillige error-paths, og man skal huske
at free() de rigtige pointere i hver eneste error-path, så kan der
nemt smutte en.

> så jeg forstår da udmærket at
> malloc gennemgås i mange tekstbøger men ikke alloca. Der står jo også:
> "alloca is a function which is not included in the ANSI C standard".

Det var jeg så ikke lige klar over, det står der ikke i min manual.

> Så
> man kan ligeså godt lære malloc() som det første, da den ikke er til at
> komme udenom.

Naturligvis skal man lære den, men når nu der findes nemmere måder,
kan man jo lige så godt tage fordelene der hvor de kan bruges.

> Derudover tror jeg ikke det er en god ide at lægge mange kilobytes eller
> megabytes data på stakken - jeg er som sagt ikke ekspert, men det er mit
> indtryk at det er stakken ikke beregnet til...

Stakken er beregnet til midlertidige variable. En streng er en variabel,
og noget der kun gælder indenfor samme blok er nødvendigvis midlertidigt.

> Ihvertfald ifb. med dos
> .com-filer mener jeg at stakken har en naturlig begrænsning på x antal
> kbytes.

64 kbytes for stack + heap tilsammen. Så om du lægger en streng det
ene eller det andet sted gør ikke nogen forskel i sig selv. Det gør
malloc's kontrolstrukturer til gengæld, jeg ved ikke hvor meget de
fylder, men den eneste "kontrol-struktur" alloca har brug for er
stack pointeren, og den har man under alle omstændigheder. Dertil
kommer så at heap'en kan blive fragmenteret, så det ikke er muligt
at oprette et array af en vis størrelse, selvom der faktisk er
nok fri plads på heap'en. Stack'en derimod bliver ikke fragmenteret.

> Hvordan det er med windows .exe-filer og andre program-filer ved
> jeg så ikke.

Stack + heap er meget større, (2 GB? noget i den størrelsesorden),
men de deler stadig det samme område.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Mon, 10 Apr 2006 00:19:15 +0200 skrev Martin Jørgensen:
>
>>Kent Friis wrote:
>>-snip-
>>
>>
>>>>>For dem der ikke er nået til C99 endnu, skulle man måske lige nævne
>>>>>alloca() - så slipper man for at holde styr på free, da den allokerede
>>>>>plads bliver frigivet når blokken slutter, ligesom normale variable.
>>>>
>>>>Hvad mener du med "når blokken slutter"?
>>>
>>>
>>>{ /* Her starter blokken */
>>> char * x = alloca(256);
>>>   
>>>   strcpy(x,"hej");
>>>   printf("%s\n",x);
>>>} /* Her slutter blokken */
>>
>>Altså jeg forstår stadigvæk ikke helt eksemplet, men jeg heller ikke
>>C-ekspert. Du reserverer plads til 256 bytes og bruger kun under 10.
>
>
> Jaja, det var jo et eksempel for at vise hvor en blok slutter,
> ikke et eksempel på optimering af buffer-størrelser.

Det jeg mente var: Den lægger stadigvæk 256 bytes ind på stakken, gør
den ikke? Eller er det en maksimal størrelse hvoraf den kun bruger de
der < 10 bytes?

>>Såvidt jeg kan se her: http://tigcc.ticalc.org/doc/alloc.html#alloca så
>>er den faktiske forskel at strengen kopieres ind på stakken istedet for
>>i heap'en (eller hvad det hedder).
>
>
> Korrekt.
>
>
>>Og det kræver at du har har en
>>funktion at kalde...
>
>
> Ikke forstået. Al C-kode ligger i funktioner, main() er også en
> funktion.

Ok... Jeg troede at stakken fungerede efter et last-in-first-out-princip
(eller er det: First-in-last-out-princip, FILO?)... Det gør den måske
ikke? Ellers bliver det jo noget problematisk at have flere
alloca-sætninger inde i den samme funktion?

>>Det burde du nok lige have gjort opmærksom på, hvis
>>jeg forstår tingene korrekt. Det fremgår ikke så tydeligt af dit
>>eksempel selvom du har omklandret koden med brackets.
>
>
> Blokken kunne også være fx en if-blok eller en while-blok.

Ok, jeg men jeg har aldrig brugt alloca, så det bare derfor jeg spørger...

>>Iøvrigt kan jeg ikke se at det skulle være noget problem at holde styr
>>på pointers'ene til brug for free(),
>
>
> Mange programmer har memory-leaks. Der findes endda programmer der
> kan finde memory-leaks i andre programmer. Og de er ikke beregnet
> specielt til begyndere, selv folk der har programmeret i mange år
> glemmer en gang imellem en free(), så programmet lige så stille
> leaker memory.
>
> Det er nemt nok at holde styr på i små programmer. Men når man
> pludselig begynder at have adskillige error-paths, og man skal huske
> at free() de rigtige pointere i hver eneste error-path, så kan der
> nemt smutte en.

Ok, klart.

>>så jeg forstår da udmærket at
>>malloc gennemgås i mange tekstbøger men ikke alloca. Der står jo også:
>>"alloca is a function which is not included in the ANSI C standard".
>
>
> Det var jeg så ikke lige klar over, det står der ikke i min manual.

Ok.

>>Så
>>man kan ligeså godt lære malloc() som det første, da den ikke er til at
>>komme udenom.
>
>
> Naturligvis skal man lære den, men når nu der findes nemmere måder,
> kan man jo lige så godt tage fordelene der hvor de kan bruges.

Jeg er nu stadigvæk lidt skeptisk overfor den, fordi jeg læste at den
ikke er med i ANSI C-standarden... Men jeg forstår godt din pointe...

>>Derudover tror jeg ikke det er en god ide at lægge mange kilobytes eller
>>megabytes data på stakken - jeg er som sagt ikke ekspert, men det er mit
>>indtryk at det er stakken ikke beregnet til...
>
>
> Stakken er beregnet til midlertidige variable. En streng er en variabel,
> og noget der kun gælder indenfor samme blok er nødvendigvis midlertidigt.

Det var netop derfor jeg mente at stakken fungerede efter det her:
First-in-last-out-princip (FILO) mener jeg det hedder...?

>>Ihvertfald ifb. med dos
>>.com-filer mener jeg at stakken har en naturlig begrænsning på x antal
>>kbytes.
>
>
> 64 kbytes for stack + heap tilsammen. Så om du lægger en streng det
> ene eller det andet sted gør ikke nogen forskel i sig selv. Det gør
> malloc's kontrolstrukturer til gengæld, jeg ved ikke hvor meget de
> fylder, men den eneste "kontrol-struktur" alloca har brug for er
> stack pointeren, og den har man under alle omstændigheder. Dertil
> kommer så at heap'en kan blive fragmenteret, så det ikke er muligt
> at oprette et array af en vis størrelse, selvom der faktisk er
> nok fri plads på heap'en. Stack'en derimod bliver ikke fragmenteret.

Det giver mening... Ja, det er lidt problematisk at heap'en bliver
fragmenteret... Har du egentligt en god definition på hvad heap'en er,
sådan på nogenlunde let-forståeligt dansk...

Det er sådan lidt et "diffust" begreb for mig...

>>Hvordan det er med windows .exe-filer og andre program-filer ved
>>jeg så ikke.
>
>
> Stack + heap er meget større, (2 GB? noget i den størrelsesorden),
> men de deler stadig det samme område.

Ok...


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Mon, 10 Apr 2006 15:42:12 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
>> Den Mon, 10 Apr 2006 00:19:15 +0200 skrev Martin Jørgensen:
>>
>>>Kent Friis wrote:
>>>-snip-
>>>
>>>
>>>>>>For dem der ikke er nået til C99 endnu, skulle man måske lige nævne
>>>>>>alloca() - så slipper man for at holde styr på free, da den allokerede
>>>>>>plads bliver frigivet når blokken slutter, ligesom normale variable.
>>>>>
>>>>>Hvad mener du med "når blokken slutter"?
>>>>
>>>>
>>>>{ /* Her starter blokken */
>>>> char * x = alloca(256);
>>>>   
>>>>   strcpy(x,"hej");
>>>>   printf("%s\n",x);
>>>>} /* Her slutter blokken */
>>>
>>>Altså jeg forstår stadigvæk ikke helt eksemplet, men jeg heller ikke
>>>C-ekspert. Du reserverer plads til 256 bytes og bruger kun under 10.
>>
>>
>> Jaja, det var jo et eksempel for at vise hvor en blok slutter,
>> ikke et eksempel på optimering af buffer-størrelser.
>
> Det jeg mente var: Den lægger stadigvæk 256 bytes ind på stakken, gør
> den ikke? Eller er det en maksimal størrelse hvoraf den kun bruger de
> der < 10 bytes?

Jo, den reserverer/allokerer 256 bytes. Som sagt var formålet at
forklare blokke - havde det været for at forklare alloca, skulle der
naturligvis have stået x = alloca(strlen("hej")+1); eller endnu
bedre, en variabel i stedet for "hej", så det er tydeligt at
størrelsen bliver bestemt på runtime, i modsætning til arrays der
(før C99) bliver bestemt på compile-time.

>>>Såvidt jeg kan se her: http://tigcc.ticalc.org/doc/alloc.html#alloca så
>>>er den faktiske forskel at strengen kopieres ind på stakken istedet for
>>>i heap'en (eller hvad det hedder).
>>
>> Korrekt.
>>
>>>Og det kræver at du har har en
>>>funktion at kalde...
>>
>>
>> Ikke forstået. Al C-kode ligger i funktioner, main() er også en
>> funktion.
>
> Ok... Jeg troede at stakken fungerede efter et last-in-first-out-princip
> (eller er det: First-in-last-out-princip, FILO?)... Det gør den måske
> ikke? Ellers bliver det jo noget problematisk at have flere
> alloca-sætninger inde i den samme funktion?

Det gør den, ja. Men det giver ikke noget problem, da de alle gælder
indtil slutningen af den blok de er allokeret i. Den blok der er
startet sidst vil også være den er slutter først.

>>>Så
>>>man kan ligeså godt lære malloc() som det første, da den ikke er til at
>>>komme udenom.
>>
>>
>> Naturligvis skal man lære den, men når nu der findes nemmere måder,
>> kan man jo lige så godt tage fordelene der hvor de kan bruges.
>
> Jeg er nu stadigvæk lidt skeptisk overfor den, fordi jeg læste at den
> ikke er med i ANSI C-standarden... Men jeg forstår godt din pointe...

Enig, man bør kun bruge den hvis man ved den findes i de relevante
compilere.

Og så kan man jo fortsætte, der findes faktisk compilere der kun forstår
K&R-style funktioner...

>>>Derudover tror jeg ikke det er en god ide at lægge mange kilobytes eller
>>>megabytes data på stakken - jeg er som sagt ikke ekspert, men det er mit
>>>indtryk at det er stakken ikke beregnet til...
>>
>>
>> Stakken er beregnet til midlertidige variable. En streng er en variabel,
>> og noget der kun gælder indenfor samme blok er nødvendigvis midlertidigt.
>
> Det var netop derfor jeg mente at stakken fungerede efter det her:
> First-in-last-out-princip (FILO) mener jeg det hedder...?

Last In First Out (LIFO). Men resultatet bliver det samme.

>>>Ihvertfald ifb. med dos
>>>.com-filer mener jeg at stakken har en naturlig begrænsning på x antal
>>>kbytes.
>>
>> 64 kbytes for stack + heap tilsammen. Så om du lægger en streng det
>> ene eller det andet sted gør ikke nogen forskel i sig selv. Det gør
>> malloc's kontrolstrukturer til gengæld, jeg ved ikke hvor meget de
>> fylder, men den eneste "kontrol-struktur" alloca har brug for er
>> stack pointeren, og den har man under alle omstændigheder. Dertil
>> kommer så at heap'en kan blive fragmenteret, så det ikke er muligt
>> at oprette et array af en vis størrelse, selvom der faktisk er
>> nok fri plads på heap'en. Stack'en derimod bliver ikke fragmenteret.
>
> Det giver mening... Ja, det er lidt problematisk at heap'en bliver
> fragmenteret... Har du egentligt en god definition på hvad heap'en er,
> sådan på nogenlunde let-forståeligt dansk...
>
> Det er sådan lidt et "diffust" begreb for mig...

Det er resten af den RAM der er reserveret til programmet. I den
ene ende ligger programmet typisk, og i den anden ende stakken. I midten
er heap'en så.

Programmet bliver indlæst når det starter, og ændrer sig normalt ikke
derefter. Stakken starter i toppen og vokser nedad (nogle CPU'er er
dog omvendte), og det memory der ligger imellem er heap'en.

Stakken er fast defineret hvordan den bruges - CPU'en har et eller
flere registre (SP, BP) og tæller dem automatisk op og ned ved
funktionskald. Ved parametre, lokale variable og alloca() er det
compilerens ansvar at sørge for at justere stack registrene.

Heap'en derimod er det malloc() og free()'s ansvar at holde styr på.
De kan gøre som de (eller rettere den der skrev de to funktioner) har
lyst til, bare de ikke begynder at flytte rundt på ting efter man
har fået en pointer til dem. Hvordan en bestemt implementation
af malloc() holder styr på hvad den har allokeret behøver man normalt
ikke bekymre sig om.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
-snip-

> Programmet bliver indlæst når det starter, og ændrer sig normalt ikke
> derefter. Stakken starter i toppen og vokser nedad (nogle CPU'er er
> dog omvendte), og det memory der ligger imellem er heap'en.

Hvor "lang afstand" er der så imellem stakken og programmet, altså i
bytes? Denne "afstand" må jo være den maksimale mængde RAM man kan
allokere...

Så hvis der er 512 MB RAM i pc'en og der er brugt 200 MB, ligger
programmet så i den ene ende og stakken tilsidst så der er 312 MB frit
til malloc eller er der andre begrænsninger, så man ikke kan bruge alle
de 200 MB der er "fri"?


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Tue, 11 Apr 2006 14:36:55 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
> -snip-
>
>> Programmet bliver indlæst når det starter, og ændrer sig normalt ikke
>> derefter. Stakken starter i toppen og vokser nedad (nogle CPU'er er
>> dog omvendte), og det memory der ligger imellem er heap'en.
>
> Hvor "lang afstand" er der så imellem stakken og programmet, altså i
> bytes? Denne "afstand" må jo være den maksimale mængde RAM man kan
> allokere...

Det kommer an på hvilen "memory model" systemet benytter. Med DOS
..COM filer, er der SVJH ialt 64 KB, med programmet i den ene ende, og
stack i den anden, så 64 KB minus størrelsen af programmet (minus
størrelsen af stacken).

Med 32-bit systemer, er det 2 GB ialt, programmet i den ene ende, og
stack i den anden. (Kan også være 1, 3 eller 4 GB, afhængig af hvordan
OS'et opdeler de 4 GB som 32 bits giver imellem kernel space og user
space).

> Så hvis der er 512 MB RAM i pc'en og der er brugt 200 MB, ligger
> programmet så i den ene ende og stakken tilsidst så der er 312 MB frit
> til malloc eller er der andre begrænsninger, så man ikke kan bruge alle
> de 200 MB der er "fri"?

Du mangler lige en ting i dine beregninger: MMU'en gør at man kan
placere memory pages hvor man har lyst, så der kan godt ligge et par
MB i starten til programmet, og et par MB i slutningen til stack. Resten
er så fri til andre programmer. Efterhånden som et program bruger mere
memory, mappes flere pages ind i programmets virtuelle hukommelse, enten
automatisk (stack) eller ved at malloc() beder systemet om mere memory. Er
der ikke nok fri RAM, kan systemet swappe en anden del af hukommelsen
ud til disk. Men set fra programmets synspunkt er afstanden mellem
program og stack 2 GB minus programmets størrelse, minus stack
størrelse (variabel).

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Tue, 11 Apr 2006 14:36:55 +0200 skrev Martin Jørgensen:
-snip-

>>Hvor "lang afstand" er der så imellem stakken og programmet, altså i
>>bytes? Denne "afstand" må jo være den maksimale mængde RAM man kan
>>allokere...
>
>
> Det kommer an på hvilen "memory model" systemet benytter. Med DOS
> .COM filer, er der SVJH ialt 64 KB, med programmet i den ene ende, og
> stack i den anden, så 64 KB minus størrelsen af programmet (minus
> størrelsen af stacken).

Det syntes jeg at jeg kan nikke genkendene til...

> Med 32-bit systemer, er det 2 GB ialt, programmet i den ene ende, og
> stack i den anden. (Kan også være 1, 3 eller 4 GB, afhængig af hvordan
> OS'et opdeler de 4 GB som 32 bits giver imellem kernel space og user
> space).

Egentligt syntes jeg at det er påfaldende at tænke på at så mange
maskiner er så utroligt tæt på den grænse på 2 GB... De fleste nye
maskiner i dag købes vel med 1 GB RAM og det er en stor flaskehals for
nogen simuleringsprogrammer som godt kunne tænke sig at bruge >2 GB at
windows har denne grænse... Jeg har kendskab til et par stykker på dtu
som netop har købt et par computere med 2 GB RAM og som nok gerne ville
købe mere, hvis det var muligt...

Men windows vista vil vel kunne adressere meget mere end 2 GB fordi det
er vel et 64 bit OS... Eller hvordan er det nu?

>>Så hvis der er 512 MB RAM i pc'en og der er brugt 200 MB, ligger
>>programmet så i den ene ende og stakken tilsidst så der er 312 MB frit
>>til malloc eller er der andre begrænsninger, så man ikke kan bruge alle
>>de 200 MB der er "fri"?
>
>
> Du mangler lige en ting i dine beregninger: MMU'en gør at man kan
> placere memory pages hvor man har lyst, så der kan godt ligge et par
> MB i starten til programmet, og et par MB i slutningen til stack. Resten

Det er lidt for avanceret for mig... Hvad er en MMU?

> er så fri til andre programmer. Efterhånden som et program bruger mere
> memory, mappes flere pages ind i programmets virtuelle hukommelse, enten
> automatisk (stack) eller ved at malloc() beder systemet om mere memory. Er

Hvad er det det betyder, at der mappes flere pages ind i programmets
virtuelle hukommelse?

> der ikke nok fri RAM, kan systemet swappe en anden del af hukommelsen
> ud til disk. Men set fra programmets synspunkt er afstanden mellem
> program og stack 2 GB minus programmets størrelse, minus stack
> størrelse (variabel).

Altså hvis maskinen kun har 512 MB RAM så mener du vil at afstanden er
512 MB minus programmets størrelse, minus variabel stack størrelse eller
hvordan?

Men det kommer måske også an på om man bruger en swap-fil i windows
eller ej......? Så kan systemet jo godt tro at det har den dobbelte
hukommelse, SVJH...?



Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Tue, 11 Apr 2006 17:48:32 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
>> Den Tue, 11 Apr 2006 14:36:55 +0200 skrev Martin Jørgensen:
> -snip-
>
>>>Hvor "lang afstand" er der så imellem stakken og programmet, altså i
>>>bytes? Denne "afstand" må jo være den maksimale mængde RAM man kan
>>>allokere...
>>
>>
>> Det kommer an på hvilen "memory model" systemet benytter. Med DOS
>> .COM filer, er der SVJH ialt 64 KB, med programmet i den ene ende, og
>> stack i den anden, så 64 KB minus størrelsen af programmet (minus
>> størrelsen af stacken).
>
> Det syntes jeg at jeg kan nikke genkendene til...
>
>> Med 32-bit systemer, er det 2 GB ialt, programmet i den ene ende, og
>> stack i den anden. (Kan også være 1, 3 eller 4 GB, afhængig af hvordan
>> OS'et opdeler de 4 GB som 32 bits giver imellem kernel space og user
>> space).
>
> Egentligt syntes jeg at det er påfaldende at tænke på at så mange
> maskiner er så utroligt tæt på den grænse på 2 GB... De fleste nye
> maskiner i dag købes vel med 1 GB RAM og det er en stor flaskehals for
> nogen simuleringsprogrammer som godt kunne tænke sig at bruge >2 GB at
> windows har denne grænse... Jeg har kendskab til et par stykker på dtu
> som netop har købt et par computere med 2 GB RAM og som nok gerne ville
> købe mere, hvis det var muligt...

Det 2 GB adresse-område gælder per program, Pentium PRO og nyere
supporterer 64 GB totalt. Hvor meget Windows kan håndtere ved jeg
ikke, men Linux supporterer op til 64 GB.

For simuleringsprogrammer er der nok kun en løsning -> 64 bit.

> Men windows vista vil vel kunne adressere meget mere end 2 GB fordi det
> er vel et 64 bit OS... Eller hvordan er det nu?

Vista 64, ja. Men så skal man også have en 64-bit PC at køre den på.
Den almindelige Vista vil nok stadig kunne køre på de 99% af
computere der ikke er 64-bit.

>>>Så hvis der er 512 MB RAM i pc'en og der er brugt 200 MB, ligger
>>>programmet så i den ene ende og stakken tilsidst så der er 312 MB frit
>>>til malloc eller er der andre begrænsninger, så man ikke kan bruge alle
>>>de 200 MB der er "fri"?
>>
>>
>> Du mangler lige en ting i dine beregninger: MMU'en gør at man kan
>> placere memory pages hvor man har lyst, så der kan godt ligge et par
>> MB i starten til programmet, og et par MB i slutningen til stack. Resten
>
> Det er lidt for avanceret for mig... Hvad er en MMU?

Memory Management Unit. Den del af CPU'en der gør at man kan flytte
rundt på RAM'en som man har lyst til, og en fysisk adresse der før
tilhørte et program (men den del er swappet ud lige nu) i stedet kan
tilhøre et andet program.

>> er så fri til andre programmer. Efterhånden som et program bruger mere
>> memory, mappes flere pages ind i programmets virtuelle hukommelse, enten
>> automatisk (stack) eller ved at malloc() beder systemet om mere memory. Er
>
> Hvad er det det betyder, at der mappes flere pages ind i programmets
> virtuelle hukommelse?

Altså, når man har 2 GB adresse-område, men kun 512 MB RAM, kan højst
en fjerdedel være "mapped" til RAM. Resten er "unmapped", og hvis
programmet forsøger at tilgå dem, vil OS'et få besked på dette, og
enten finde de data der skulle ligge på det sted (fra swap), eller
give en fejl (segmentation fault / general protection fault).

Pages er blot små blokke af RAM, typisk 4 KB (på Intel). Det er den
mindste størrelse MMU'en kan håndtere.

>> der ikke nok fri RAM, kan systemet swappe en anden del af hukommelsen
>> ud til disk. Men set fra programmets synspunkt er afstanden mellem
>> program og stack 2 GB minus programmets størrelse, minus stack
>> størrelse (variabel).
>
> Altså hvis maskinen kun har 512 MB RAM så mener du vil at afstanden er
> 512 MB minus programmets størrelse, minus variabel stack størrelse eller
> hvordan?

Nej, afstanden set fra programmets synspunkt (pointere) er 2 GB
minus program minus stack. Noget af disse 2 GB "mangler" så, men
det ved programmet ikke noget om. For hvis den forsøger at få
fat i dem, flytter OS'et rundt på tingene inde bagved (evt ved at
swappe noget andet ud), så der er RAM på den plads. Der bliver så
bare et hul et andet sted.

> Men det kommer måske også an på om man bruger en swap-fil i windows
> eller ej......? Så kan systemet jo godt tro at det har den dobbelte
> hukommelse, SVJH...?

Swap-filen har ikke indflydelse på programmets adresse-område, men
den har naturligvis indflydelse på hvornår OS'et går fra at flytte
rundt på data til at returnere "out of memory".

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
-snip-

>>Altså hvis maskinen kun har 512 MB RAM så mener du vil at afstanden er
>>512 MB minus programmets størrelse, minus variabel stack størrelse eller
>>hvordan?
>
>
> Nej, afstanden set fra programmets synspunkt (pointere) er 2 GB
> minus program minus stack. Noget af disse 2 GB "mangler" så, men
> det ved programmet ikke noget om. For hvis den forsøger at få
> fat i dem, flytter OS'et rundt på tingene inde bagved (evt ved at
> swappe noget andet ud), så der er RAM på den plads. Der bliver så
> bare et hul et andet sted.
-snip-

osv...

Jaja, så lærte jeg også noget nyt i dag...


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Kent Friis skrev:

> For dem der ikke er nået til C99 endnu, skulle man måske lige
> nævne alloca()

Hvad så hvis man ikke er nået til den? Det er måske derfor at
lærebøgerne ikke omtaler den?

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Kent Friis skrev:
>> For dem der ikke er nået til C99 endnu, skulle man måske lige
>> nævne alloca()
>
> Hvad så hvis man ikke er nået til den? Det er måske derfor at
> lærebøgerne ikke omtaler den?

Kent skrev faktisk "ikke nået".

Alloca er gammel.

Alloca er sikkert ikke nævnt i nyere lærebøger - der er
sådan lidt 1980'agtigt over den funktion.

Arne

---

Den Sun, 09 Apr 2006 19:53:13 -0400 skrev Arne Vajhøj:
> Bertel Lund Hansen wrote:
>> Kent Friis skrev:
>>> For dem der ikke er nået til C99 endnu, skulle man måske lige
>>> nævne alloca()
>>
>> Hvad så hvis man ikke er nået til den? Det er måske derfor at
>> lærebøgerne ikke omtaler den?
>
> Kent skrev faktisk "ikke nået".
>
> Alloca er gammel.
>
> Alloca er sikkert ikke nævnt i nyere lærebøger - der er
> sådan lidt 1980'agtigt over den funktion.

Men det er da ikke nogen undskyldning for ikke at lære folk om en så
smart funktion, der først er blevet mere eller mindre overflødig med
C99.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
-snip-

> Men det er da ikke nogen undskyldning for ikke at lære folk om en så
> smart funktion, der først er blevet mere eller mindre overflødig med
> C99.

Jeg fangede ikke lige helt: Hvorfor er det den er overflødig med C99?


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Mon, 10 Apr 2006 15:43:17 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
> -snip-
>
>> Men det er da ikke nogen undskyldning for ikke at lære folk om en så
>> smart funktion, der først er blevet mere eller mindre overflødig med
>> C99.
>
> Jeg fangede ikke lige helt: Hvorfor er det den er overflødig med C99?

Fordi der kan man skrive:

char c[strlen(a)+strlen(b)+1];
   
i stedet for

char * c = alloca(strlen(a)+strlen(b)+1);

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Mon, 10 Apr 2006 15:43:17 +0200 skrev Martin Jørgensen:
>
>>Kent Friis wrote:
>>-snip-
>>
>>
>>>Men det er da ikke nogen undskyldning for ikke at lære folk om en så
>>>smart funktion, der først er blevet mere eller mindre overflødig med
>>>C99.
>>
>>Jeg fangede ikke lige helt: Hvorfor er det den er overflødig med C99?
>
>
> Fordi der kan man skrive:
>
> char c[strlen(a)+strlen(b)+1];
>    
> i stedet for
>
> char * c = alloca(strlen(a)+strlen(b)+1);

Ok... Men nu kan min compiler (Visual studio 2005) vist ikke forstå C99,
så det er ikke noget jeg kan afprøve.

Men måske kan cc eller g++ compileren forstå C99? Eller også kommer det
an på alle de utallige "mystiske" compiler options, som jeg overhovedet
ikke orker at sætte mig ind i...

Jeg er relativt nybegynder...


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Tue, 11 Apr 2006 14:40:08 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
>> Den Mon, 10 Apr 2006 15:43:17 +0200 skrev Martin Jørgensen:
>>
>>>Kent Friis wrote:
>>>-snip-
>>>
>>>
>>>>Men det er da ikke nogen undskyldning for ikke at lære folk om en så
>>>>smart funktion, der først er blevet mere eller mindre overflødig med
>>>>C99.
>>>
>>>Jeg fangede ikke lige helt: Hvorfor er det den er overflødig med C99?
>>
>>
>> Fordi der kan man skrive:
>>
>> char c[strlen(a)+strlen(b)+1];
>>    
>> i stedet for
>>
>> char * c = alloca(strlen(a)+strlen(b)+1);
>
> Ok... Men nu kan min compiler (Visual studio 2005) vist ikke forstå C99,
> så det er ikke noget jeg kan afprøve.

Nej, man skal nok ikke forvente at Microsoft kan nå at implementere det
på 6 år (1999-2005) Det er jo først i VC++ 7.0 (er det ikke sådan
den hedder) at de har fået C++ for-løkker implementeret korrekt.

> Men måske kan cc eller g++ compileren forstå C99? Eller også kommer det
> an på alle de utallige "mystiske" compiler options, som jeg overhovedet
> ikke orker at sætte mig ind i...

GCC 3.x forstår de fleste C99-ting. GCC 2.96.x forstår lidt færre. Fx er
runtime allokerede arrays (ovenstående) supporteret i gcc 2.96.x,
hvorimod at erklære variable andre steder end i starten af blokken (C++
style) først er med fra 3.x.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Tue, 11 Apr 2006 14:40:08 +0200 skrev Martin Jørgensen:
-snip-

>>>>Jeg fangede ikke lige helt: Hvorfor er det den er overflødig med C99?
>>>
>>>
>>>Fordi der kan man skrive:
>>>
>>>char c[strlen(a)+strlen(b)+1];
>>>   
>>>i stedet for
>>>
>>>char * c = alloca(strlen(a)+strlen(b)+1);
>>
>>Ok... Men nu kan min compiler (Visual studio 2005) vist ikke forstå C99,
>>så det er ikke noget jeg kan afprøve.
>
>
> Nej, man skal nok ikke forvente at Microsoft kan nå at implementere det
> på 6 år (1999-2005) Det er jo først i VC++ 7.0 (er det ikke sådan
> den hedder) at de har fået C++ for-løkker implementeret korrekt.

Det ved jeg ikke... Jeg har kun programmeret i C og C++ et par måneder,
men har adgang til en gratis studie-version af visual studio 2005 som
jeg nu bruger...

>>Men måske kan cc eller g++ compileren forstå C99? Eller også kommer det
>>an på alle de utallige "mystiske" compiler options, som jeg overhovedet
>>ikke orker at sætte mig ind i...
>
>
> GCC 3.x forstår de fleste C99-ting. GCC 2.96.x forstår lidt færre. Fx er
> runtime allokerede arrays (ovenstående) supporteret i gcc 2.96.x,
> hvorimod at erklære variable andre steder end i starten af blokken (C++
> style) først er med fra 3.x.

Uhada... De sover ikke timen... Jeg kører med bl.a. med (på en anden pc):

$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5247)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Tue, 11 Apr 2006 17:51:41 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
>> Den Tue, 11 Apr 2006 14:40:08 +0200 skrev Martin Jørgensen:
> -snip-
>
>>>Men måske kan cc eller g++ compileren forstå C99? Eller også kommer det
>>>an på alle de utallige "mystiske" compiler options, som jeg overhovedet
>>>ikke orker at sætte mig ind i...
>>
>>
>> GCC 3.x forstår de fleste C99-ting. GCC 2.96.x forstår lidt færre. Fx er
>> runtime allokerede arrays (ovenstående) supporteret i gcc 2.96.x,
>> hvorimod at erklære variable andre steder end i starten af blokken (C++
>> style) først er med fra 3.x.
>
> Uhada... De sover ikke timen... Jeg kører med bl.a. med (på en anden pc):
>
> $ gcc --version
> powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
> 5247)

GCC 4.0 er stadig meget ny. GCC 2.96.x har længe været den anbefale
compiler til Linux kernen, da 3.x havde problemer - ikke kun fejl i
compileren, men også kernen der simpelthen brugte nogle ting forkert
som gav det rigtige resultat i den gamle version... Men nu er 3.x
vist kommet med.

Derudover har jeg ikke lige været den hurtigste til at opgradere, så
jeg har nok været lidt bagud (opgraderede fra 2.96.x til 3.4.4). Når
man som jeg installerer fra source, skal man helst sætte en dags tid
af til at installere en ny compiler. Ikke så meget fordi den tager
lang tid at compile (en halv time tror jeg), men fordi at når først
man har installeret den, hvis den så ikke virker så har man et
problem. For man kan jo ikke compile en ny når compileren ikke
virker...

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> GCC 4.0 er stadig meget ny. GCC 2.96.x har længe været den anbefale
> compiler til Linux kernen, da 3.x havde problemer - ikke kun fejl i
> compileren, men også kernen der simpelthen brugte nogle ting forkert
> som gav det rigtige resultat i den gamle version... Men nu er 3.x
> vist kommet med.

Er det mig som husker forkert eller er 2.96 den specielle
"Redhat" version mens de rigtige GNU versioner
gik fra 2.95.3 til 3.0 ?

Arne

---

Den Tue, 11 Apr 2006 21:19:07 -0400 skrev Arne Vajhøj:
> Kent Friis wrote:
>> GCC 4.0 er stadig meget ny. GCC 2.96.x har længe været den anbefale
>> compiler til Linux kernen, da 3.x havde problemer - ikke kun fejl i
>> compileren, men også kernen der simpelthen brugte nogle ting forkert
>> som gav det rigtige resultat i den gamle version... Men nu er 3.x
>> vist kommet med.
>
> Er det mig som husker forkert eller er 2.96 den specielle
> "Redhat" version mens de rigtige GNU versioner
> gik fra 2.95.3 til 3.0 ?

Sorry, min fejl. Det var naturligvis 2.95.3 jeg mente. Det er hvad der
sker når man ikke checker hvad man havde installeret.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Tue, 11 Apr 2006 17:51:41 +0200 skrev Martin Jørgensen:
-snip-

> Derudover har jeg ikke lige været den hurtigste til at opgradere, så
> jeg har nok været lidt bagud (opgraderede fra 2.96.x til 3.4.4). Når
> man som jeg installerer fra source, skal man helst sætte en dags tid
> af til at installere en ny compiler. Ikke så meget fordi den tager
> lang tid at compile (en halv time tror jeg), men fordi at når først
> man har installeret den, hvis den så ikke virker så har man et
> problem. For man kan jo ikke compile en ny når compileren ikke
> virker...

Så kan man vel downloade en binary et sted?


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Wed, 12 Apr 2006 20:29:29 +0200 skrev Martin Jørgensen:
> Kent Friis wrote:
>> Den Tue, 11 Apr 2006 17:51:41 +0200 skrev Martin Jørgensen:
> -snip-
>
>> Derudover har jeg ikke lige været den hurtigste til at opgradere, så
>> jeg har nok været lidt bagud (opgraderede fra 2.96.x til 3.4.4). Når
>> man som jeg installerer fra source, skal man helst sætte en dags tid
>> af til at installere en ny compiler. Ikke så meget fordi den tager
>> lang tid at compile (en halv time tror jeg), men fordi at når først
>> man har installeret den, hvis den så ikke virker så har man et
>> problem. For man kan jo ikke compile en ny når compileren ikke
>> virker...
>
> Så kan man vel downloade en binary et sted?

Hvis man brugte distributionens pakkesystem, kunne man godt - og
dog, for jeg tror ikke der findes nyere end 2.95.3 til SuSE 7.0,
og jeg nægter at opgradere til nyere versioner.

Egentlig er det meningen at jeg vil have en Debian eller Ubuntu på
maskinen, men jeg gider ikke geninstallere. Det er jo ikke Windows
det her

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Egentlig er det meningen at jeg vil have en Debian eller Ubuntu på
> maskinen, men jeg gider ikke geninstallere. Det er jo ikke Windows
> det her

Det er heldigvis heller ikke nødvendigt... ;)
http://www.debian.org/releases/stable/i386/apcs04.html.en

--
Bo Andresen

---

Den Wed, 12 Apr 2006 21:42:01 +0200 skrev Bo Ørsted Andresen:
> Kent Friis wrote:
>> Egentlig er det meningen at jeg vil have en Debian eller Ubuntu på
>> maskinen, men jeg gider ikke geninstallere. Det er jo ikke Windows
>> det her
>
> Det er heldigvis heller ikke nødvendigt... ;)
> http://www.debian.org/releases/stable/i386/apcs04.html.en

Haps, bookmarked.

Jeg kendte godt debootstrap, har været begyndt på projektet en gang,
men da havde jeg ikke nogen howto, så jeg opgav inden jeg nåede så
langt. Den forudsætter dog at man har en fri partition at installere
på, så det er vel stadig principielt en geninstallation, selvom det
foregår imens det gamle system gører. Allerhelst ville jeg om man
kunne starte med apt-get, og så hente en ting ad gangen efterhånden
som man opgraderer alligevel, præcis som jeg har gjort med SuSE RPM
-> source.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:

> Allerhelst ville jeg om man kunne starte med apt-get, og så hente en
> ting ad gangen efterhånden som man opgraderer alligevel, præcis som
> jeg har gjort med SuSE RPM -> source.

Jeg har tidligere haft held med at installere en Gentoo i en chroot
inden i en anden Linux installation. Når jeg var færdig kunne jeg bare
boote en LiveCD og flytte rod-bibliotekerne rundt. Tæller det også som
en geninstallation?

--
PeKaJe

Linux has a history of standing on the shoulders of giants, while Microsoft has
a history of trying to break giants' legs. The latter is quite less efficient.

---

Den 22 Apr 2006 09:14:49 GMT skrev Peter Jensen:
> Kent Friis wrote:
>
>> Allerhelst ville jeg om man kunne starte med apt-get, og så hente en
>> ting ad gangen efterhånden som man opgraderer alligevel, præcis som
>> jeg har gjort med SuSE RPM -> source.
>
> Jeg har tidligere haft held med at installere en Gentoo i en chroot
> inden i en anden Linux installation. Når jeg var færdig kunne jeg bare
> boote en LiveCD og flytte rod-bibliotekerne rundt. Tæller det også som
> en geninstallation?

Du startede jo så fint med ordet "installere".

Problemet er nok at jeg godt ved jeg aldrig ville få taget mig sammen
til at færdiggøre projektet, der vil altid være et eller andet jeg
mangler. Derfor ville en glidende overgang være at foretrække.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Martin Jørgensen wrote:
> Kent Friis wrote:
>> Nej, man skal nok ikke forvente at Microsoft kan nå at implementere det
>> på 6 år (1999-2005) Det er jo først i VC++ 7.0 (er det ikke sådan
>> den hedder) at de har fået C++ for-løkker implementeret korrekt.
>
> Det ved jeg ikke... Jeg har kun programmeret i C og C++ et par måneder,
> men har adgang til en gratis studie-version af visual studio 2005 som
> jeg nu bruger...

2005 er version 8.0

Arne

---

Kent Friis wrote:
> Den Sun, 09 Apr 2006 19:53:13 -0400 skrev Arne Vajhøj:
>> Alloca er gammel.
>>
>> Alloca er sikkert ikke nævnt i nyere lærebøger - der er
>> sådan lidt 1980'agtigt over den funktion.
>
> Men det er da ikke nogen undskyldning for ikke at lære folk om en så
> smart funktion, der først er blevet mere eller mindre overflødig med
> C99.

Jeg tror der er 2 grunde:

1) den kom ikke med i ANSI C

2) den skal implementeres i compileren og ikke i runtime library

nogen gange kom den sikkert ikke med i første version af
compileren

nogen gange har runtime library folkene forsøgt med en uheldig
implementation (jeg har set en funktion som blev kaldt og i.s.f.
at lave en return så jumpede den tilbage til retur adressen)

Arne

---

Hej.

Bertel Lund Hansen wrote:

> [...]i erklæringen og
>
>    array=malloc(size);
>

Burde dette ikke være:

   array = malloc(size * sizeof(int));

I Jacks post er size antallet af elementer i arrayet, og ikke
(byte)størrelsen af arrayet.

Og som BLH skriver, husk:

   free(array);

Når du er færdig med at bruge arrayet.

Venligst

--
Bjarke Freund-Hansen <bjarkef@tnb.aau.dk>

---

Bjarke Freund-Hansen skrev:

> Burde dette ikke være:

>    array = malloc(size * sizeof(int));

Jo.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Jack L. wrote:
> Hej gruppe.
>
> MS Visual.NET C/C++ [...]

Beslut dig: Skriver du i C eller i C++?

De svar du har fået indtil videre har antaget C.

Hvis vi antager C++, så er svaret: Nej, du kan ikke definere arrays i
C++ hvor størrelsen ikke er kendt på oversættelsestidspunktet. Brug
std::vector i stedet.

mvh. Anders

---

Anders J. Munch wrote:
> Jack L. wrote:
>> Hej gruppe.
>>
>> MS Visual.NET C/C++ [...]
>
> Beslut dig: Skriver du i C eller i C++?
>
> De svar du har fået indtil videre har antaget C.
>
> Hvis vi antager C++, så er svaret: Nej, du kan ikke definere arrays i
> C++ hvor størrelsen ikke er kendt på oversættelsestidspunktet. Brug
> std::vector i stedet.
>
> mvh. Anders

Hej, du har ret, jeg skulle bruge svaret i C. Jeg vil kigge paa tilsvarende
for C++ senere, men tak til jeres alles hjaelp. :)


--
Mvh. / Best regards,
Jack L.,
Copenhagen, EU