On 02/02/2011 08:46 AM, Andrzej Jarzabek wrote:
> 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.

Możliwe, chociaż wydaje mi się, że akurat o paddingu standard C też nic
nie mówi. Więc tak czy inaczej jesteś w krainie konkretnego kompilatora.

>>> 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.

Pewnie, że można, ale nie wiem, czy się robi, za to każdy kompilator C
ma te rozszerzenia. Co to za argument o wołaniu funkcji? W C++ nie
musisz wołać?

>>> 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.

Jeśli czytam przy co 20 pakiecie, to prawdopodobnie znaczy to, że wyszło
mi z pierwszego rzutowania, że w danym pakiecie mam dodatkowe dane w
innym formacie, czyli robię kolejne rzutowanie i dopiero wtedy wołam
funkcję. Możemy się tak licytować do śmierci, bo nie działamy na
konkretnym przykładzie.

> 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.

Prawdopodobny scenariusz, ale tak samo masz w C++ - jeżeli nagle masz
buga, którego "poprawiasz" w ten sposób, że zmieniasz interface klasy
(bo przecież kontrakt przed bugiem był taki, że wartość była zwracana
"as is", czyli jako big endian), to co za różnica? Dalej i tak ktoś
robił sobie ntohla na własną rękę, bo przecież wcześniej dostawał
network order a potrzebował "native order".

>> 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".

W tym momencie nie przekłada się. Przekłada się na poziomie całego
projektu. W TYM MOMENCIE, czyli dokładnie w tym, o którym mówimy,
grzebiesz po bajtach i musisz uważać w każdym języku. Nawet jak masz
język, w którym opisujesz pakiet w XMLu, możesz zapomnieć o tym, o czym
pisałeś wyżej, to znaczy nie uwzględnić, że dana jest w big endian.

> 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.

Ogólnie się zgadzam, ale zwróć uwagę, że podany wyżej przykład jest
bardzo konkretny i bardzo statyczny - dotyczy TYLKO odczytania jakiegoś
bufora, a nie operacji na nim, w dodatku w przypadku, kiedy dane mają
bardzo dobrze określony format - dane wysyłane przez sprzęt zwykle nie
zmieniają się razem z widzimisię klienta. Zwykle.

> 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.

Kompletnie nie rozumiem, co to ma wspólnego z tematem.

JD