T.M.F. pisze:
> W dniu 15.10.2009 11:25, Konop pisze:
>>> Oj, jednak pola bitowe sa czytelniejsze. No i jesli zmienisz ich
>>> kolejnosc to nie pociaga to potem zazwyczaj uperdliwej zmiany we
>>> wszytkich plikach.
>>
>> Z kolejnością się nie zgodzę!! Tworzę jeden plik nagłówkowy i tam
>> umieszczam wszystkie definicje - nie ma problemu ze zmianą kolejności
>> ;D...
>> Jest jedno "za" tą metodą (i z tego względu tego też używałem). Z tego,
>> co gdzieś kiedyś czytałem [potrzebne źródło ;)] to kompilator ma prawo
>> dowolnie rozmieścić pola bitowe w bajcie. Niekoniecznie będą więc one
>> umieszczone w kolejności wpisywania... w momencie, w którym chce się
>> potem taki bajt gdzieś "wyświetlić", to koniecznie trzeba wiedzieć który
>> bit co oznacza, a używając pól bitowych (dwukropka ;)), możemy tego nie
>> wiedzieć...
>
> Cos sie zapetliles, to w koncu te pola bitowe sa rozmieszczane dowolnie
> czy nie?

Nie no, w MOIM ;) rozwiązaniu kolejność łatwo zmienić i jest ona
"pewna", a w polach bitowych też łatwo zmienić, ale jest ona niepewna...

> IMHO kompilator rozmieszcza je w kolejnosci w jakiej sa zdefiniowane - w
> koncu to struktura, a elementy struktury wystepuja w kolejnosci zgodnej
> z definicja.

Poszukam gdzieś informacji, bo na pewno gdzieś to czytałem... ale czy to
było wiarygodne źródło, to nie wiem... ale tak swoją drogą, robisz
strukturę (zapis skrócony):
Pole1 : 3
Pole2 : 4
Pole3 : 6
Pole4 : 1
Pole5 : 2

Proc o dostępie do pamięci bajtowym... jak pamięć przydzieli
kompilator?? Jak wrzuci jak leci, to Pole3 będzie podzielone pomiędzy
dwa bajty?? Czy może najstarszy bit zostanie "pusty" i Pole3 zacznie się
od drugiego bajtu - wówczas całość zajmie 3 bajty... a może kompilator w
ten 1 wolny bit pierwszego bajtu wrzuci Pole4??

Pozdrawiam
Konop