eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingktóre języki 'historyczne' są ważneRe: które języki 'historyczne' sš ważne
  • Data: 2011-02-02 07:46:35
    Temat: Re: które języki 'historyczne' sš ważne
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: