Andrzej Jarzabek wrote:

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

Teoretycznie możliwe, w praktyce jeszcze tego nie widziałem.

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

Jeśli akurat mi w danym momencie na czymś takim zależy i akurat używam C++,
to robię klasę o nazwie fd_guard_t (analogiczną do lock_guard z nowego
standardu). I dalej operuję na nie-opakowanym deskryptorze.

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

Do formatowania do pliku, czy na stdout, rzeczywiście może być wygodniejsze
użycie FILE* lub iostream. Natomiast ich interfejs nie pasuje do sensownej
obsługi np. połączeń sieciowych, gdzie przed wywołaniem funkcji nie wiadomo
ile bajtów będzie się dało w tej chwili odczytać/zapisać. W takim wypadku
lepszy jest jawny podział na dwie części: formatowanie do pamięci, a
następnie przerzucenie w jednym lub wielu etapach przez deskryptor.

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

Można. Z tym że nie wiem, czemu miałoby to być "sensowniejsze". Jest tak
samo sensowne jak POSIX-owe, tylko z innym interfejsem.

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

Wątków akurat unikam jak mogę. Łatwiej się testuje dwa współpracujące
procesy, niż dwa współpracujące wątki. API opakowujące pthreads nie
wniosłoby mi w tej kwestii absolutnie nic.

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

Porównuję do czasu od którego istnieją systemy Uniksowe. Większość założeń
jest już bardzo starych, ale jednak przez bardzo wiele lat standard się
jeszcze rozwija.

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

Nie widziałem jeszcze przypadku pomylenia inta zawierającego deskryptor z
intem zawierającym liczbę przeczytanych bajtów. Ta zaleta jest czysto
teoretyczna.