Re: re: visual c 7.1 bug?

[szabolcs.ber...@szuro.hix.hu]

Azert nem latod a kulonbseget, mert elmeletileg nincs kulonbseg: az if kore tet
tem egy '{}'-t.

Az i deklaracioja tenyleg be lehet tenni a for scope-jaba, de az eredmeny ugyan
az.

A fura az, hogy belep a ciklusba, de onnan rogton ki is lep, nem megy vissza a
for elennorzesi reszehez. Optimalizalas nelkul forditottam, szoval debug kozben
vissza kellene hogy ugorjon ra...

Szabi

(webes bekuldes, a bekuldo gepe: catv-5062b26c.catv.broadband.hu)

[szabolcs.ber...@szuro.hix.hu]

> Miert nem visszafele szamoltok?

Mert az ujsagot sem visszafele olvasom.

> ....
> for(i=buf.count-1; i!=0; i--)
> ....
>
> Az 0-val osszehasonlitas gyorsabb mindenfajta
> procin, es a forditonak is konnyebb dolga van vele.
> Tehat: kevesebb hiba, es az utasitas-atlapolas is jobb > lesz.

Ezekben te egeszen biztos vagy??
A forditonak konnyebb dolga van. Szegeny, nehogy mar elfaradjon. Inakabb kezzel
mikrooptimalizalok assembly-ben.
Kevesebb hiba: miert is??
A 0-val valo osszehasonlitas: hanyszor nezted meg, hogy egy fordito milyen kodo
t general a C forrasodbol? Meg fogsz lepodni. Akarmennyire probalkozol, _nem_ t
udod megmondani, hogy milyen kodot fog generalni. Ha epp ugy jon ki a lepes, me
g veletlenul sem lesz benne az a teszt, amit te C-ben irtal.

Szoval roviden: felesleges mikrooptimalizalni C-ben.

Eloszor algoritmikus optimalizalas, utana esetleg profiling es kezzel ujrairod
asm-ban a lassu reszeket. De ez utobbival csak akkor kell probalkozni, ha masho
gy semmikeppen nem tudod megoldani, mert konnyen elofordulhat, hogy a te kezzel
optimalizalt valtozatod lassabb lesz...

Bocs a kioktatasert, de erdemes neha megnezni, hogy mit general a fordito...