On 02/02/2011 14:19, Jędrzej Dudkiewicz wrote:
> On 02/02/2011 02:52 PM, Andrzej Jarzabek wrote:
>>
>> Mówi, że może być i ogólniej, że konkretny binarny layout struktury
>> jest zależny od implementacji.
>
> W C++ to samo.

Ale w C++ można to lepiej rozwiązać inaczej, niż rzutując na strukturę.

>>> Więc tak czy inaczej jesteś w krainie konkretnego kompilatora.
>> A w C++ możesz właśnie nie być.
>
> Jak robisz ręczny, dokładny dostęp pole po polu, to pewnie, że może być.
> W C też tak możesz napisać. Ba, w C++ możesz napisać tak, jak jest w C,
> i też będzie pięknie.

Wcale nie będzie pięknie: będzie kaszaniasto.

>>> 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.
>
> Ta funkcja jest wołana w jednym miejscu. Wołanie funkcji w jednym
> miejscu uważam za non-issue. To zupełnie inna skala problemu niż ręczne
> wołanie odpowiednika destruktora.

Funkcja wołana jest w jednym miejscu, być może. Ale takich funkcji masz
np. 87, dla 163 różnych formatów komunikatów: dla jednych wołasz na
początku, dla innych nie, dla innych wołasz, jak chcesz uzyskać dostęp
dla jakiegoś konkretnego pola. Prawdopodobieństwo wprowadzenia błędu
przy takim projekcie i nie wywołania w pewnym miejscu którejś z tych
funkcji, albo wywołania nie tej, co trzeba, jest wysokie.

>> Wyszło powiedzmy tyle, że w danym pakiecie masz jakieś inne pola,
>> niekoniecznie w innym formacie.
>
> Jak to jakieś inne pole w niekoniecznie innym formacie? Znaczy mam tę
> samą strukturę, tylko z innym polem? To znaczy mam tę samą strukturę,
> czy jednak nie?

Elementarne drogi Watsonie. Jeśli struktura ma więcej niż jedno pole, to
oprócz tego, że ma jakieś określone, to ma również inne. Ta sama struktura.

>>> czyli robię kolejne rzutowanie i dopiero wtedy wołam
>>> funkcję.
>>
>> Jakie to proste i wygodne!
>
> A w C++ co zrobisz? To samo.

Np. napiszę klasę wrapującą bufor bajtowy z funkcjami dostępu. Jeśli np.
na wejściu będę sądził, że dane pole jest czytane w jenym miejscu, to
zrobię konwersję przy odczycie. Jeśli okaże się, że to założenie się nie
sprawdziło, że program wykonuje za dużo konwersji i powoduje to
niedopuszczalną utratę performance'u, to sobie np. zcache'uję wynik.
Zachowując jednocześnie 100% kompatybilności z kodem klienckim.

Dodatkowo jeśli chcę modyfikować bufor w klasie, to mogę wskaźnik na
niego schować w klasie, w ten sposób mając wysoką dozę
prawdopodobieństwa, że dalszy kod przetwarzający nie będzie miał do
niego dostępu.

> Skoro masz nagle dane, które masz inaczej
> interpretować (bo nie wierzę, że jednak masz tę samą strukturę z innymi
> polami - w głowie mi się taka mutacja nie mieści), to musisz ustalić,
> jako co masz interpretować. Bierzesz bajt/zmienną identyfikującą dane w
> binarnym buforze, wybierasz odpowiednią klasę i karmisz ją buforem.

I daję taką klasę do dalszego przetwarzania, przez co nie ma możliwości,
żeby obsługujący kod przez pomyłkę wywołał funkcję przeznaczoną dla
innej struktury, albo ie wywołał jakiejś funkcji, którą powinien wywołać
przy odczycie jakiegoś pola.

> No i to jest dokładnie to, co napisałem wcześniej. W C++ masz wszystko
> ładnie zapakowane, ale zwykle w opakowaniu siedzi jakiś syf.
>
> Może tak: ja uważam, że grzebanie się w bajtach i w bitach to jest
> grzebanie w gnoju i niezależnie od tego, czy robisz to w kombinezonie
> czy w kąpielówkach, pozostanie to grzebaniem w gnoju.

OK, ja tylko nie zgadzam się z tezą, że C jakoś szczególnie dobrze się
do tego nadaje - bo już C++ nadaje się lepiej.

> Sprawę należy
> załatwić szybko, powstały kod hermetycznie zamknąć w jakiejś klasie i o
> całości zapomnieć. Dlatego uważam, że rzutowanie wskaźnika na bufor na
> wskaźnik na strukturę jest równie dobrym rozwiązaniem jak każde inne. O
> ile nie jest to powszechna technika.

Właśnie nie jest równie dobre, choćby dlatego, że nie daje hermetycznego
zapakowania.