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

[SZIGETI Szabolcs]

Hali!

Ez az cast. Az (UXCHAR)ch azt jelenti, hogy a ch valamilyen típusú, de te
UXCHAR típusúként szeretnéd használni valami okból. Két példa:

int a,b;
double c;

a=5;
b=2;

c=a/b;

Itt c értéke 2 lesz, mert a és b is int, tehát integer osztást fog
végrehajtani, aminek az eredménye 2, és ez kerül c-be (ő hiába double már
ilyenkor).

Ha a fenti helyett

c=(double)a/b;

-t írsz, akkor helyes eredményt fogsz kapni, mert az osztás legalább egyik
tagja nem integer, tehát lebegőpontos osztást fog végrehajtani.

Másik példa:

typedef struct { ... tökmindegy ... } adatelem;

adatelem *ap;

ap=(adatelem*) malloc (sizeof (adatelem);

Itt csak a szépség kedvéért csináljuk, mert a malloc (void*) típusú mutató
ad vissza és meg akarjuk nyugtatni a fordítót, magunkat, meg bárki mást aki
majd a kódunkat olvassa, hogy tudjuk, hogy itt egy adatelem struktúrára
mutató mutatóként akarjuk használni.

Összefoglalva, a castinggal adattípusokat tudunk egymásba átalakítani.
Egyébként legtöbbször pointer típusokat akarunk változtatni. Vigyázni kell,
mert nagyot lehet ezekkel bukni, ha pontosan nem tudjuk mi történik, hiszen
a pointerek konvertálása során a fordító nem nézni, hogy van-e értelme  az
egésznek, vagy nincs.

Példa. Meg akarjuk nézni, hogy hogyan tárolja a memóriában a bájtokat a
rendszer.

int t[10];

char *p;

p=t; /* Ez ugye ugyanaz, mint p=&t[0]; */

for (i=0; i<10*sizeof (int); i++) {
  printf("%d. bájt: %x\n", i, *(p+i));
}

No, ez nem fog működni, mert t típusa int-re mutató pointer, p-é meg
char-ra és ugye ezek ugyan minkét esetben csak memória címet jelölnek, a
fordító mégis tudja, hogy a t+1 meg a p+1 más jelent, mivel más a mutatott
típus mérete.
Ezért, hogy kényszerítsed a fordítót ezt kell írnod:

p=(char *)t;

Azaz először t-t explicit módon átalakítod char pointerre és így már
értékül adható.

Szabolcs




2013. február 14. 14:03 Skandar Graun írta, <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]
>