On Feb 2, 11:06 am, Jędrzej Dudkiewicz <jedrzej.dudkiew...@nospam-
gmail.com> wrote:
> On 02/02/2011 08:46 AM, Andrzej Jarzabek wrote:
>
> >> __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.

Mówi, że może być i ogólniej, że konkretny binarny layout struktury
jest zależny od implementacji.

> Więc tak czy inaczej jesteś w krainie konkretnego kompilatora.

A w C++ możesz właśnie nie być.

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

NIe każdy, przynajmniej nie w takiej postaci.

> Co to za argument o wołaniu funkcji? W C++ nie
> musisz wołać?

Nie musisz, znaczy możesz napisać tak, żeby się sama wołała.


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

Wyszło powiedzmy tyle, że w danym pakiecie masz jakieś inne pola,
niekoniecznie w innym formacie.

> czyli robię kolejne rzutowanie i dopiero wtedy wołam
> funkcję.

Jakie to proste i wygodne!

> Możemy się tak licytować do śmierci, bo nie działamy na
> konkretnym przykładzie.

Przykład jest wystarczająco konkretny. W C++ w każdej takiej sytuacji
możesz stworzyć klase opakowującą bez żadnych narzutów, a decyzje o
tym, kiedy konwetować, czy za każdym dostępie, czy na miejscu, czy
trzymać wynik zcache'owany osobno zostawić implementacji.