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:
>
> > 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?

Brawo, proponuję jeszcze udowodnić, że w ogóle nie ma żadnych
istotnych różnic między językami, bo jak posadzisz małpę przed
komputerem i nauczysz ją walić w klawisze, to w dowolnym języku
doprowadzi program do postaci, w której się nie kompiluje lub nie
uruchamia.

A różnica jest choćby taka, że jak masz wyspecyfikowany kontrakt,
mówie zwraca w formacie natywnym. Czy może nawet inaczej: różnica
polega na tym, że w ogóle można mówić o jakimś kontrakcie.

> Dalej i tak ktoś
> robił sobie ntohla na własną rękę, bo przecież wcześniej dostawał
> network order a potrzebował "native order".

Oprócz działania bez sensu, masz jednak kilka sensownych alternatyw,
których nie masz w C.

> >> Tak czy owak, zaletą C++ jest to, że jakby co, to można tego rozwiązania
> >> użyć, ale znacznie ładniej zapakowanego.
>
> > Ale "ładinej 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.

W tym momencie się właśnie przekłada. Bo "nadaje się do" nie sprowadza
się tylko do tego, że można napisać kawałek kodu, który zrobi to czy
owo, bo to niewątpliwie można w C zrobić, tylko jak potem ten kawałek
kodu funkcjonuje w kontekście całego projektu. To, jak to zrobisz ma
znaczenie dla tego, jak prawdopodobne jest to, że ktoś piszący kod
kliencki użyje tego, co zrobiłeś, nieprawidłowo, teraz lub kiedyś w
przyszłości - i tym kimś równie dobrze możesz być ty sam.

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

Oczywiście. Ale, dla przykładu, projektując taki XML możesz (w
zależności od tego, do czego będzie stosowany) założyć, że typ 'int32'
jest defaultowo big endian, niezależnie od architektury procesora,
albo że musisz endianness podać jawnie. W takiej sytuacji trudniej o
pomyłkę, w szczególności popełnioną przez programistę, który przez n
lat pisał systemy na architekturach big endian i przyzwyczaił się, że
można sobie po prostu rzutnąć inta 'bo działa'.

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

wiesz, nie ja ten przykłd wymyśliłem. Ale tutaj też masz zaletę C++:
jak programista dostanie strukturę, to może np. założyć, że
modyfikować bufor może przypisując wartości do pól struktury. Jak
dostanie obiekt z getterami ale bez setterów, to będzie musiał już się
trochę zastanowić.

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

Język, w którym można pisać re-usable i przenośne biblioteki przydatne
w jakichś zastosowaniach, lepiej się nadaje do tych zastosowań od
języka, w którym nie można.