---

Jeg forstår ikke det her:


I en øvelse har jeg bl.a. følgende erklæringer lokalt i en procedure:

type
TOejne = 2..12;
TOejeSum = array[TOejne] of Integer;

var
OejeSum : TOejesum;
Sum : Integer;



I *samme procedure*


Vil jeg udskrive indholdet af Oejesum i en memoen HyppighedMemo:

for Sum := 2 to 12 do
HyppighedMemo.Lines.Add( IntToStr(OejeSum[Sum]) );

Det virker faktisk. Men pga. en anden fejl satte jeg et break og nogle
watches, som det ses her:

   http://www.nf.suite.dk/kast.gif

Billedet viser det sted, hvor OejeSum 2, 3 og 4 er skrevet korrekt ud.

Men når jeg stepper igennem, går Sum *nedad* fra 11 i Watch List.

På billedet er den nået *ned* til 8, og OejeSum[8] angives korrekt som
127. Men det er altså OejeSum[5] = 113, der korrekt skrives ud som
det næste.

Ingen af variablerne eller nogen med samme navne er erklæret udenfor
den pågældende procedure.

Er der en bug i debuggeren?


Venlig hilsen

Niels Foldager

---

Tråden "FAQ" henviser til:

http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm


hvor der under pkt. 9 står:

----------------------------
9. Why does the debugger show my For loop variable counting down, not
up?

The Delphi optimizer may generate loop code that decrements an
internal counter instead of your variable. This behavior is guaranteed
not to alter the correctness of your program. Ignore the debugger
value and consider the For loop variable "unavailable due to
optimization".
----------------------------


For mig er det godt nok mystisk, hvordan det skulle indgå i en
optimering. Men så er det altså ikke en fejl.

Det er ellers ikke sjældent, man har brug for at følge en
tæller-variabel eller sætte break-betingelser for den.

Kan man slå optimeringen fra, mens man debugger sit program?

Venlig hilsen

Niels Foldager

---

> For mig er det godt nok mystisk, hvordan det skulle indgå i en
> optimering. Men så er det altså ikke en fejl.

Det er mere effektivt at teste om tælleren er 0 end om den er x. Derfor
denne optimering.

> Kan man slå optimeringen fra, mens man debugger sit program?

Ja, brug {$O-} compiler direktiv. Det kan også sættes i project > options >
compiler.

hilsen
Uffe

---

Uffe Kousgaard:


> Det er mere effektivt at teste om tælleren er 0 end om den er x. Derfor
> denne optimering.

Interessant detalje.

Men så skal man jo hele tiden "spejle" tælleren, så den indgår rigtigt
i for-to-loopets kode-linie?


> > Kan man slå optimeringen fra, mens man debugger sit program?

> Ja, brug {$O-} compiler direktiv. Det kan også sættes i project > options >
> compiler.

OK. Men det ændrede nu ikke på, at den tæller den "forkerte" vej.

Venlig hilsen

Niels Foldager

---

> OK. Men det ændrede nu ikke på, at den tæller den "forkerte" vej.

Det er et punkt som Borland har fået meget (berettiget) skældud for.
Hvis forklaringen er rigtig (hvad jeg ikke tror) så er det min mening at
det er en meget forkert måde at løse et optimerings problem på, når man
tænker på det antal spildte timer verden over der er gået netop med
dette problem (mine egne inklusive).
Da jeg i sin tid (De gode DOS dage) havde meget fokus på hurtige
afviklings tider brugte jeg en compiler (Stony Brook Pascal) der kunne
kompilere samme kode som Borlands compiler og var derfor direkte
sammenlignelig.
Koden fyldte mindre og var optil 200 gange hurtigere i visse
situationer. Så hvis optimering lå Borland så meget på sinde, så er der
nok andre ting de kunne tage fat på uden at compileren laver kode der
ser forkert ud når man debugger på det.
Dette er ikke en kritik af Delphi som udviklings værktøj, Jeg har selv
brugt Delphi næsten siden det kom frem, og hvis man vil programmere i
Pascal er det nok også (i dag) svært at få noget der er bedre.
For dem der skulle have brug for en compiler der laver kompakt og hurtig
32 bit kode (jeg bruger den stadig til komando linie opgaver) prøv at se
www.vpascal.com Der bliver ikke udviklet på den mere men jeg synes at
den virker fint til mange opgaver. For dem der kender turbo/borland
Pascal vil genkendelsens glæde være stor.

Carsten

---

"Carsten" <mail@no-mail.dk> wrote in message
news:42d21f37$0$17252$edfadb0f@dread11.news.tele.dk...
>
> Det er et punkt som Borland har fået meget (berettiget) skældud for.

Jeg har set mange undre sig indtil de fik det forklaret, men aldrig set
nogen skældud. Måske fra begyndere, der har brugt tid på at forstå det?

Generelt får Borland en del kritik for at de ikke optimerer deres kode nok
ift. andre kompilerer.

> Koden fyldte mindre og var optil 200 gange hurtigere i visse situationer.

Det må vidst så være undtagelsen, der bekræfter reglen. Normalen har nok
nærmere været lige hurtig kode.

> For dem der skulle have brug for en compiler der laver kompakt og hurtig
> 32 bit kode

Hurtig er ofte i modstrid med kompakt. "Loop unfolding" er et eksempel på
det. Man dropper en løkke og duplikerer koden i stedet.

hilsen
Uffe