On Friday, December 4, 2015 at 2:18:45 PM UTC+1, Maciej Sobczak wrote:
> > Rozmawialiśmy o
> > szczególikach, typu:
> > 1) można się przejechać na big/lit endian
> > 2) najpierw memcpy, potem operator rzutowania
> > 3) różny padding w strukturach
> > 4) różny rozmiar inta na różnych platformach lub wersjach programu.
>
> Właśnie te szczególiki powodują, że te triki to złe rozwiązania.

Mają swoje zalety. Gdy mam dużą strukturę, którą będę modyfikował w
przyszłości i gdy użyję:
write( &struct , sizeof(struct) , 1 )
to:
1) w jednej linii kodu zapisuję/odczytuję całą strukturę.
2) strukturę mogę dowolnie modyfikować, a zapis i odczyt zawsze
zadziała.


> > aktywne unikanie tego ryzyka zajmuje
> > czas. Zobacz jak łatwo rypnąć się po poprawce pól w strukturze.
>
> Jeśli problemem jest czas lub poprawki pól w strukturach (ale przecież protokół
miał być znany?), to taki kod można wygenerować. Po to są standardy w rodzaju ASN.1 i
jemu podobne. Albo nawet niestandardowe, ale poręczne wynalazki typu MessagePack.
> Co do czasu - ogólnie, pisanie poprawnych programów może zająć więcej czasu, niż
niepoprawnych. Ale akurat poprawna obsługa protokołu sieciowego to jest jedno z tych
miejsc, gdzie oszczędność czasu na etapie kodowania się nie opłaca.

Zgodzę się z Tobą, ale tylko w przypadku bardzo dużych aplikacji. W mały i w
średnich programach to co proponujesz moim zdaniem jest przerostem
formy nad treścią.

Pozdrawiam