On 02/02/2011 01:01, Jędrzej Dudkiewicz wrote:
> On 02/02/2011 01:06 AM, Andrzej Jarzabek wrote:
>>
>> Naprawdę? Szkoda tylko, że jak piszesz tę strukturę, to musisz pilnować,
>> żeby wszystkie pola były na swoim miejscu i żeby Ci kompilator nie
>> namieszał paddingiem na przykład.
>
> __attribute__((packed)), pola struktury nie mogą być przekładane.

To nie jest zdaje się część standardowego języka C, tylko rozszerzenie,
które twórca implementacji dodał dlatego właśnie, że C się do tego
kiepsko nadaje.

>> Jak w C zapiszesz pole pakietu, które jest zaczyna się od ósmego bajta i
>> jest czterobajtową liczbą, powiedzmy bez znaku, zapisaną w formacie -
>> uwaga - big endian?
>
> Rozumiem, że chodzi o deklarację tego pola w strukturze? Otóż wstawię na
> początek pól na łączną wartość 7 bajtów, potem wstawię czterobajtową
> zmienną, a potem wywołam funkcję "preprocess_packet", która mi zawoła
> ntohl i pochodne na wskazanych polach, w tym na tej zmiennej.

Jeśli oprócz castowania należy jeszcze rozszerzyć język i do tego
jeszcze wołać funkcje, to w praktycznie każdym języku imperatywnym można
mieć równie "proste i wygodne" rozwiązanie, a w wielu można to zrobić
prościej, wygodniej i przenośnie.

>> W C++ za to możesz bez problemu wrapnąć bufor bajtowy w klasę, która
>> jako dane pole udotępnia ci dajmy na to 14 bajt bufora albo wartość
>> liczbową w natywnym formacie, zapisaną jako big endian na bajtach od 4
>> do 7.
>
> Jasne, ale w środku albo będziesz kopiował dane do oddzielnych pól, albo
> będziesz trzymał wskaźniki do nich i wołał ntohl przy dostępie, albo
> wstawisz powyższy syf. To trzecie ma najmniejszy narzut pamięciowy i
> obliczeniowy w czasie wykonania.

Nieprawda. Jeśli np. czytasz wartość tego pola tylko w co 20 pakiecie,
to mniejszy narzut ma konwertowanie przy dostępie.

Modyfikowanie bufora ma z kolei taki problem, że łatwo wprowadzić buga:
wyskakuje w testowaniu błąd, dopisujesz funkcję preprocess_packet, a
tymczasem inny programista napisał jakiś kawałek kodu,, który gdzieś
dalej korzysta z założenia, że pod tym wskaźnikiem znajduje się
poprawnie sformatowany pakiet.

> Tak czy owak, zaletą C++ jest to, że jakby co, to można tego rozwiązania
> użyć, ale znacznie ładniej zapakowanego.

Ale "ładiuej zapakowane" w tym momencie przekłada się właśnie na "nadaje
się do". Na przykład - bez żadnej straty wydajności - powoduje, że
trudniej wprowadzić błędy, w szczególności w zmianach dokonywanych wiele
miesięcy po napisaniu pierwotnego kodu. Albo że można to samo zrobić
przenośnie - co z kolei oznacza, że zamiast pisać kod do
obsługi/parsowania pakietów na swoją implementację, można skorzystać z
dobrze przetestowanej biblioteki third-party.