[elektro] C-ben bit struktura kérdés

hg12345 hg12345 at freemail.hu
Thu Jun 12 15:26:22 CEST 2008


Köszönöm a válaszokat.

nehezen tudok olyamit megfogalmazni aminek nincs meghatározása.
Összafoglalnám....

1, a sizeof() függvényt csak olyan változokra lehet használni aminek a 
C-ben mérete van.
 a fordító szerinti általában a lekisebb méret amire számol az a char! a 
sizeof() ennek a méretben adja meg az értéket.
 
2. a bitmezőnek nincs mérete (persze a fordító nyilvántartja).

3. a bit mezőket a GNU esetén szigoruan növekvő sorrendben helyezi 
el, és az elhelyezéset kiveszi az optimalizálás alol.
   Sajnos elég buta, mert az optimalizásnál a bitmező csak egy 
maszkolási müveletet jelent a fordítónak és a utána mint teljes
   regiszter kezeli az optimalizáció során.((pl.: Ez egy 3bites egybe 
kezelendő polling változó esetén katasztrofához vezet (befagy a 
program))).
   
3. amit leírtam csak lehetséges megadások voltak, amiket szinkronba 
szeretnék hozni.
  (Tudásom szerint nem lehet... reméltem valaki már rájött a 
megoldásra )

4. Tudtommal az ansi C ismeri az anonimus union és strukt de nem 
szólóban, csak más strukt és union-ba beágyazva.
   Amit használok forditó GNU ebben a formában nem emészti. Igy 
szólóban egyedileg bit változókat nem lehet megadni.
   Igy a IAR-C esetén lehetséges megadásokat nem tudom 
használni....   
   
5. ha union-ban használod
   union {
	   long Value;
	   struct {
	     unsigned  A:2;
	     unsigned  B:5;	   	
	   }
	}
  a fenti esetben kivédhetőek az áthelyezések és byte határra 
ígazitások.
  A "C" szerintem nem byte-t határra igazit, hanem az int értelmezési 
határra ez az alap tárolási méret. 
  
 
Sajnos szükséges bitmezöket használnom a program felépítésénél.
Igy vannak olyan helyzetek amikor egybe szeretnék használni több 
bitmezőt nem nulla viszgálatra, mert ennek hibátlan az optimalizációja...
Ilyen esetekben kerülendő egy halom maszkoló utasítást, ezért 
szeretném sajátkézbe venni a megoldást.
Ezekre az esetekre kéne, hogy a bitmező poziciója kinyerhető lenne a 
meghatározásából.
Amig erre nincs megoldás marad kettős meghatározás, és ennek 
minden veszélye.
    

> hg12345 wrote:
> > A bit strukturák és a hozza tartozó define-k összekapcsolására van 
> > szabványos megoldás. (nem találtam :-)
> > 
> > pl.:
> > 
> > union {
> >           unsigned int A;
> >           struct {
> >              bit0:1;
> >              bit1:1;
> >              bit2:1;
> >            }
> >          } WORD;
> > 
> > #define WORDbit0      0
> > #define WORDbit1      1
> > 
> > vagy 
> > enum eWORD{WORDbit0=0,WORDbit1,WORDbit2};
> > 
> > WORD.A ^= 3<<WORDbit1;
> > 
> > A fenti megoldásra szeretnék egy olyat a bitstrukturából tudja 
kinyerni 
> > a bit poziciót.
> > 
> > (((Akár a forditott megoldás is jó, hogy a #define-ból el&#337;állítja a 
> > bitstrukturát, mondjuk ez kevésbó jó, mert sokkal macerásabb és 
> > érthetetlenebb, föleg ha minden bitnek eltér&#337; neve van)))
> 
> 
> Nem teljesen ertem a feladatot. Miert kell ket kulonbozo elnevezest 
hasznalni?
> WORD.A ^= 3<<WORDbit1;
> Helyett miert nem jo a WORD.bit2^=1 ?
> 
Mert a 3 nem 1!  0b11 van 0b1 helyett.

> (meg egyebkent nem WORDbit2-t akartal irni?)

Nem ez egy anonnimus struktura a megadása igy jó
> 
> > Tudom létezik olyan C ami ismeri a bit szint&#369; pointer, de erre nem 
> > vágyom. Amit eltudnék képzelni forditási idöben is létez&#337; sizeof() 
> > függvény ?
> 
> Tudomasom szerint mukodik forditasi idoben a sizeof() minden olyan 
dologra 
> aminek ismert a merete forditasi idoben.
> 
> -- 
> ((( Móczik Gábor  )))--((( E~mail: "pm-01" 
@AT "progzmaster" .DOT "hu" )))
> ((( Skype: moczik )))
> 
> -----------------------------------------
>           elektro[-flame|-etc]
> 

________________________________________________________
Te már megnézted, hogy diszlexiásak-e a gyerekeid?

Találtam egy szülőknek szóló diszlexiatesztet, amit egy perc alatt kitölthetsz. A legjobb, hogy ha gond van, akkor abban is segítenek, hogy kihez fordulj. Ja, és ez egy ingyenes oldal, nem kerül semmibe. Kattints ide: www.diszlexiateszt.hu/i.php?id=fr080609 



More information about the Elektro mailing list