[ekg2-devel] Pola zamiast act w window_t

[GiM]

Michał Górny in message 'Re: [ekg2-devel] Pola zamiast act w window_t' wrote:
> On Sun, Feb 10, 2008 at 11:03:37PM +0100, GiM wrote:
> > b) czytelność kodu (chociażby samej struktury) spada,
> 
> Mógłbyś jakoś konkretniej? Bo ja, szczerze, nie widzę tutaj problemu —
> pola są, jak były, tylko czasem się malutki dwukropek z cyferką wkrada
> za ich nazwą (nie da się ukryć, że IMO lepiej byłoby przed). Ładnie
> wyindentować i różnicy praktycznie nie ma.
> 

nie do końca o to mi chodziło.
developer który będzie chciał dołączyć do projektu, moim zdaniem będzie
miał utrudnione zadanie. pozatym oczywiste jest, że nie wszędzie
można stosować pola bitowe, więc i tak część elementów będzie :x
a część bez.

> > c) łatwo _bardzo_ (o czym już pisał dj) o błędy,
> 
> Błędy… acz z drugiej strony, wymuszamy w tym momencie ujawnienie się
> wszystkich obecnie działających paskudztw. Potem może okazać się, że
> i tak jakaś inna modyfikacja spowoduje, że wszystko zacznie się sypać.
>

szczerze mówiąc, nie jestem w stanie sobie wyobrazić, jaka inna
modyfikacja mogłaby spowodować, że wszystko się zacznie sypać.
zamiana na pola bitowe moim zdaniem jest najprostszą zmianą, która
może spowodować że 'wszystko zacznie się sypać'.

> Z drugiej strony, trochę żal, że gcc nie ostrzega przed wpisaniem
> w pole bitowe większej wartości.
> 

co do tego co dj pisał, to się nie zgadzam to jest możliwe,
ale to byłby bezsensowny narzut czasowy.

> > d) gcc i tak to przerabia jak chce, więc zysk pamięciowy
> >    może mieć przebicie na czas (no to chyba zawsze jest taki
> >    trade pamięć vs. czas),
> 
> IMO akurat w przypadku komunikatora internetowego, ktĂłry raczej
> programem o wysokim priorytecie nie jest, akurat powinniśmy kierować się
> przede wszystkim ku minimalizacji zużycia pamięci. Nie robimy tyle
> rzeczy, żeby naprawdę nam zależało na oszczędności czasu procesora;
> za to zdarza nam się całymi dniami w wielu kopiach siedzieć w pamięci.
> 

no ale ile tej pamięci można zaoszczędzić?
wydaje mi się, że jest 100 innych miejsc, gdzie można potunningować
pamięć z lepszymi efektami niż zmieniając elementy struktur na pola
bitowe

> > e) pomijając C++, to chyba inne języki nie mają pól bitowych
> >    i ludzie jakoś sobie radzą i z tym żyją....
> 
> VFAT nie ma dziennikowania. Windows nie ma socketów uniksowych. Tak więc
> mamy we wszystkich innych systemach plików usunąć dziennikowanie, i pod
> żadnym pozorem nie używać socketów uniksowych w programie skierowanym
> tylko i wyłącznie do systemów GNU?
> 

no ale jesteś w stanie podać przykład jakiejś aplikacji user-space
[komunikatora najlepiej, żeby było porównanie], gdzie używają
pĂłl bitowych?

ja rozumiem jeszcze pola :1 jako boolean, ale wszystkie większe
to imho nieporozumienie.

> > g) ewentualne zwiększanie pola bitowego (e.g. bo chcemy kolejny
> >    ficzer) to psucie ABI
> 
> Jeśli chcemy kolejny ficzer, to raczej nie zwiększamy pola, tylko robimy
> nowe, adekwatnie nazwane. Przecież o to chodzi, nie? Jeśli dodamy je na
> końcu, to bodajże ABI nic się nie stanie. Swoją drogą, o ile się
> nie mylę, to grupa pól bitowych i tak wyrównywana jest do określonego
> pochodnego typu, więc do pewnego stopnia możńa dokładać nowe bity
> w środku.
> 

chodziło mi, że nagle zechcesz zmienić blah:3 na blah:5, psuje ABI?
psuje.

Jak już pisałem wyżej, dla mnie sens pól bitowych jedynie z :1

wprowadzenie pól bitowych to nie jest coś o co mam zamiar walczyć,
bo chyba nie robi mi to aş takiej róşnicy, ale to jest bardzo prosty
sposĂłb na prawdopodobne rozwalenie ekg2. a babole ktĂłre po tym
zostaną (bo wydaje mi się, że jednak pojawiłyby się), mogłyby się
ciągnąć niezauważone miesiącami.

 czołem, Michał Spadliński
-- 
 main(int a[puts("Michal 'GiM' Spadlinski")]){}
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: nie znany
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /mailman/pipermail/ekg2-devel/attachments/20080213/ad3a36b6/attachment.bin