[elektro] A szokásos C kezdő kérdések

[Vajk Fekete]

gyonyoru!!!

veszem a ch charactert, a zarojeles ize castolja, azaz atkenyszeriti a
tipusat valami unsigned szamnak. kivonom belole az elso betut reprezentalo
szamot, igy megkapom szamkent hogy hanyadik betu. Ezt a szamot hozzaadom a
karaktertomb elejere mutato pointerhez, igy a ch karakternek megfelelo
elemre mutato pointert kapok. az ez altal mutatott struktura width elemet
veszem, es hozzaadom a textWidth-hez.

Vajk

2013/2/14 Skandar Graun <sgraun at gmail.com>

> Sziasztok...
> Mámegint próbálok értelmezni...
>
> textWidth += (pChTable + ((UXCHAR)ch - (UXCHAR)fontFirstChar))->width;
> ez a "(UXCHAR)ch" hogy értelmezendő?
> Itt a szintaxis a lényeg, hogy mit képzeljek oda, mit értelmezzek, nem
> a tényleges nevek.
>
> C30, még mindig.
>
>
> hg12345 <hg12345 at freemail.hu> írta (2013. január 31. 15:55):
> > Hi,
> >
> > Vajk Fekete <vajkhu at gmail.com> írta:
> >>egy beagyazott rendszer egesz mas tema. Amugy a tema nagyon erdekes,>
> > tulajdonkeppen reszben arrol beszelunk hogy az architektura tervezes,>
> > modularizalas, optimalizalas mennyire elkulonitheto, es milyen
> sorrendben>
> > kell legyenek.>
> >>
> > egy beagyazott cuccnal siman az egesz architektura mulhat azon, hogy az>
> > adott funkcio belefer-e 64 orajelbe vagy sem. ha igen, akkor lehet az>
> > ISR-ben, ha nem akkor egesz mashova kell keruljon, vagy akar lehet hogy>
> > akkor nem interrupt alapura kell tervezni.>
> >
> >
> > Azért talán mamár talan nem ennyiré vészes, néhány cent különbségért
> kapsz DMA-t és 2,3x nagyobb segességú eszközt
> >
> >>
> > Vajk>
> >>
> > 2013/1/31 Móczik Gábor <pm_levlista at progzmaster.hu>>
> >>
> >> 2013.01.31. 10:50 keltezéssel, SZIGETI Szabolcs írta:>
> >> > lesz az. Persze kijelentve mindezt mindenféle analízis és mérés
> nélkül.>
> >> > Aztán amikor nagy nehezen sikerült rábeszélni egy profilingra, akkor>
> >> > kiderült, hogy halálra optimalizálta a teljes futási idő 0,1%-ért
> felelős>
> >> > kódrészt, ami így 25%-kal gyorsabb lett. vagyis nyert az egész futási>
> >> időn>
> >> > 0,025%-ot. És kerek szemekkel nézte, hogy volt egy függvény, amiben>
> >> 50%-ot>
> >> > ment a program. Ezt pár egyszerű fogással durván ötödére lehetett>
> >> faragni.>
> >>>
> >> Ez jól hangzik egy PC-n, szerveren, ahol legfeljebb vársz 3
> másodperccel>
> >> többet egy eredményre, de egy real-time rendszerben, mondjuk egy>
> >> mikrokontrolleres vezérlőrendszerben ez egyszerűen nem működik.>
> >>>
> >> Lehet hogy egy adott interrupt csak az idő 0.1%-ában fut, de akkor>
> >> mondjuk adott igen szűk időkeret alatt valamit tenni kell. A CPU>
> >> sebessége véges, és ha a lefordított kód nem fut le ennyi idő alatt,>
> >> akkor valamit faragni kell.>
> >>>
> >> Nem ritka.>
> >>>
> >> > Szóval először működjön funkcionálisan jól, a kód legyen olvasható,>
> >> > hordozható, karbantartható. Aztán mérünk és megnézzük, hogy tényleg
> lassú>
> >> > vagy nagy-e és ha igen, akkor a mérés alapján megnézzük, hogy hol
> kell>
> >> > faragni. Itt jöhet aztán a bitvadászat, de rendszerint nagyon kevés>
> >> esetben>
> >> > kell vadászni, primitív dolgokkal (pl. egymásba ágyazott ciklusok
> ki/meg>
> >> > fordítása, jobb adatszerkezet, stb.) hatalmasakat lehet nyerni. De
> ehhez>
> >> > mérni és elemezni kell.>
> >>>
> >> Ezzel mondjuk egyetértek. Nem kell mindent optimalizálni, csak azt ami>
> >> nem felel meg, és azt is úgy, hogy minél kevésbé legyen speciális.>
> >>>
> >> ----------------------------------------->
> >>           elektro[-flame|-etc]>
> >>>
> > ----------------------------------------->
> >           elektro[-flame|-etc]>
> >
> >
> > -----------------------------------------
> >           elektro[-flame|-etc]
>
> -----------------------------------------
>           elektro[-flame|-etc]
>