eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingDlaczego w branży rozrywkowej najsłabiej płacą?Re: Dlaczego w branży rozrywkowej najsłabiej płacą?
  • Data: 2011-10-13 00:31:21
    Temat: Re: Dlaczego w branży rozrywkowej najsłabiej płacą?
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 12/10/2011 23:51, Wojciech Jaczewski wrote:
    > Andrzej Jarzabek wrote:
    >>
    >> Do pisania oprogramowania niezawodnego potrzebna jest abstrakcja i
    >> czytelność kodu. Kod, który sobie po cichu zakłada, że int ma 32 bity ma
    >> niedobory w jednym i drugim.
    >
    > Mowa o funkcjach systemowych, a nie zakładaniu ile bitów ma int. Trudno mi
    > sobie wyobrazić, aby ktoś korzystał z tego założenia, mając do dyspozycji
    > alternatywę w postaci int32_t.

    Ja mówię o tym i o tym. A przykład z intem z życia wzięty: profesor to
    właśnie napisał ledwie kilka dni temu.

    > Bardzo jest dla mnie zagadkowe, że tak wiele osób uważa, iż interfejs
    > opracowywany i testowany przez kilka dziesięcioleci koniecznie wymaga
    > opakowania w jakąś abstrakcję, bo inaczej korzystać z niego nie należy...

    Cała sztuka porządnego pisania większych programów polega na przejściu
    między końcową funkcjonalnością a wykorzystywanymi bibliotekami przez
    wiele warstw abstrakcji - i wyrażeniu tych abstrakcji w kodzie.

    > Nie wiem jak jest z interfejsami windowsowymi, bo z nimi doświadczenie
    > miałem znikome, ale interfejsy POSIX-owe są bardzo dobre. Abstrakcja w
    > postaci deskryptora pliku - coś wspaniałego.

    Właśnie kaszanka. Przykładowo, jeśli mówimy o niezawodności, to sam
    fakt, że deskryptor jest typem liczbowym ułatwia popełnienie błędu
    polegającego na tym, że jako deskryptora używasz liczby, która
    deskryptorem nie jest.

    Kolejny problem z deskryptorami jest taki, że łatwo przez pomyłkę o kod,
    który w pewnych sytuacjach nie zamyka deskryptorów, które otwiera, np.
    na wskutek early return czy rzucenia wyjątkiem.

    Dalej, jeśli np. próbujesz zrobić formatowane wyjście na deskryptor
    przez ręczne babranie się z alokowaniem buforów, kopiowaniem i
    sklejaniem stringów, jakimiś dodatkowymi funkcjami do formatowania
    liczb, to masz całą masę pomyłek, które łatwo popełnić z katastrofalnymi
    skutkami: dangling pointers, bufer overflow, memory leaks, czy dany
    string jest null-terminated czy nie itd. itp.

    > Również dla krytykowanych przez niektórych uniksowych sygnałów daje się
    > czasem znaleźć fajne zastosowanie, gdzie bez sygnałów program byłby dużo
    > bardziej zawiły.

    Również dla sygnałów unixowych są abstrakcje, które będą zwykle
    sensowniejsze do stosowania niż systemowe API, na przykład w modelu
    programu, który obsługuje jakieś zdarzenia sygnał może wsytępować po
    prostu jako jeden z typów "zdarzeń".

    Kolejne unixowe API którego łatwo przez pomyłkę użyć nieprawidłowo i
    rozwalić program to choćby pthreads.

    > Oczywiście w każdym API dałoby się wskazać jakieś wady, ale na jakiej
    > podstawie miałbym przypuszczać, że zrobiona w dużo krótszym czasie
    > abstrakcja będzie istotnie lepsza?

    Dlaczego zakładasz, że w dużo krótszym czasie? Jeśli mówimy o
    generycznych abstrakcjach na system operacyjny, to jak pisałem są to
    albo istniejące i szeroko stosowane biblioteki third party, albo też
    rozwiązanie in house stosowane w wielu produktach danej firmy i często
    rozwijane latami.

    > Dla mnie "opakowywanie systemowego API" to takie wynalazki jak np. QSocket z
    > Qt. Dla programów międzyplatformowych - może ma sens. Dla programów na jedną
    > platformę - żadnego.

    Nie znam Qt, więc się nie wypowiem. Zapewne ewidentną zaletą tago
    rozwiązania jest to, że nie da się pomylić inta zawierającego deskryptor
    z intem zawierający liczbę przeczytanych bajtów.

    > Interfejs udostępniany przez system (POSIX) jest
    > lepszy. Testowałem też kiedyś Boost::Asio - nieczytelny w porównaniu z tym,
    > co można zrobić korzystająć bezpośrednio z POSIX. I ciężki do integracji,
    > jeśli program ma reagować jednocześnie na zdarzenia innego typu.

    Nie mam doświadczenia z tym, ale pracowałem kiedyś z event handling
    frameworkiem opakowującym unixowe API i praktyka jednak była taka, że
    nowy typ zdarzeń był do niego dodawany dużo, dużo rzadziej niż pisanie
    programów, które korzystały tylko z już obsługiwanych typów.

    >> Pracowałem przy kilku większych projektach i normą było korzystanie z
    >> biblioteki opakowującej API, chociaż nie takiej, która jest tworzona pod
    >> konkretny projekt: albo były to biblioteki third party, albo robione w
    >> firmie na potrzeby wielu projektów. To, czy korzystają czy nie
    >> korzystają ze wszystkich funkcji API nie ma znaczenia - istotne jest, że
    >> reprezentują wyższy poziom abstrakcji.
    >
    > Czy wyższy poziom abstrakcji w sensie np. baza danych zamiast bezpośredniego
    > czytania z plików i synchronizowania przy pomocy fcntl/flock? czy tylko
    > pozbierane kilka funkcji systemowych do kupy i pozamykane w obiekty?

    Można mieć różne poziomy abstrakcji do różnych rzeczy. Dla pliku
    chociażby możesz mieć poziom abstrakcji mówiący, że jest strumieniem, że
    po zakończeniu działań na nim jest zamykany, na innym poziomie
    abstrakcji możesz mieć wyrażony fakt, że jest fizycznym plikiem na
    dysku, że np. program zapisuje określone dane do pliku o określonej
    ścieżce, na wyższych poziomach masz semantykę: plik może być bazą
    danych, logiem, dokumentem o zadanym formacie, plikiem konfiguracyjnym
    itd. Brak odpowiedniego opakowania może choćby spowodować błąd
    polegający na tym, że ktoś potraktuje plik XML z fiflakami jako plik
    binarny zawierający bazę danych fiflaków lub odwrotnie.

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: