>>	for (count = 0, i = 0; i < buf.use; i++)
> for(i=buf.count-1; i!=0; i--)
Szerintem ez a nyero: for(i = buf.use; i--;)
Szep nyelv a C...

u.i.:Ez a szoveg mitol angol? A sok angol parancstol? A CODER-nal
igazan lehetne egy kicsit valtoztatni az aranyon: nem sok programozasi
nyelv letezik, ami magyarul irhato...

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)

> 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...

Szabi

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