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.