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

[Skandar Graun]

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]