Biblioteka stara si� by� do wszystkiego, od zabytk�w z lat chyba 60-tych po
Bluetooth. Przez to kod korzystaj�cy z biblioteki wygl�da strasznie,
wsz�dzie zb�dne wska�niki - nawet do zwyk�ego inta, a jeszcze obok podajemy
jego rozmiar!
Zdaj� sobie spraw�, �e protoko�y maj� gdzieniegdzie warto�ci little endian,
ale mo�na by�o to przed programist� ukry�, nie zmuszaj�c do r�cznej
konwersji w niewiadomo kt�r� stron�, niewiadomo w kt�rych miejscach. Mn�stwo
niesp�jno�ci.
Wsz�dzie zb�dne skr�ty, w��czaj�c w to potworki typu WSAEACCES (bo drugie S
na ko�cu by�oby ju� chyba za d�ugie).
Internet raz nazywa siďż˝ INET, gdzie indziej In, a jeszcze gdzie indziej IP.
Wiele p�l w strukturach ma nie wiedzie� po co dziwaczne nadmiarowe
przedrostki (np. S_un_w).
Pary sta�ych np. WSAECANCELLED i WSA_E_CANCELLED o r�nych warto�ciach.
Do wyboru sockety blokuj�ce (czekaj�ce do wieczno�ci bez mo�liwo�ci
anulowania operacji), nieblokuj�ce (przepraszaj�ce nas �e istniej�) i
asynchroniczne, podczas gdy wygodniejsze by�oby co� pomi�dzy pierwszymi
dwoma.
Funkcje o ma�o wyszukanych nazwach accept, select czy connect. Tutaj te�
niesp�jno�� a� niewiarygodna: gethostbyname ale GetNameByType.
I ten ca�y bajzel w imi� czego? Zgodno�ci z jakim� unikso-posiksem sprzed 30
lat? Po co?
--
Azarien
Ale przecież to co piszesz dotyczy w 90% Windows a nie "innych systemów".
JD
PS. Do API socketów nic nie mam od czasu, jak musiałem napisać trochę
kodu w motifie (w zasadzie w lesstifie, ale jeden pies).
> Ale przecież to co piszesz dotyczy w 90% Windows a nie "innych systemów".
Twierdzisz, że sockety w "innych systemach" są jakoś magicznie zupełnie
inne?
> PS. Do API socketów nic nie mam od czasu, jak musiałem napisać trochę kodu
> w motifie (w zasadzie w lesstifie, ale jeden pies).
Nie znam.
--
Azarien
Bo pod Windows na gwałt potrzebowano aplikacji sieciowych, dodano
Winsock i portowano, co się da, albo pisano za pomocą programistów
znających interfejs BSD sockets. A wszystko to niecałe 20 lat temu.
Potem już tylko zgodność interfejsów...
--
Paweł Kierski
ne...@pkierski.net
przecieďż˝ tego API nie dodano do Windowsa wczoraj, tylko circa about 20 lat
temu. to, �e interfejs, kt�ry adoptowano, ma jak�� konwencj� kejsingu, a
windowsowy ma innďż˝ - to akurat nie jest nic dziwnego - w API Windows
wyst�puj� chyba wszystkie mo�liwe konwencje nazewnicze.
nazw funkcji nie ma co si� czepia� - one przysz�y z adoptowanego interfejsu.
Wiktor Zychla
Nie przypominam sobie na innych systemach WSAEACCESS, In, WSAECANCELLED,
GetNameByType.
Fragment o "zgodności z jakimś unikso-posiksem sprzed 30 lat" dotyczyć
może tylko Windows, bo na innych systemach to jest po prostu stare API,
nie zmieniane w imię zgodności wstecznej.
Co do wskaźników na int i ich rozmiarów - nie wszędzie rozmiar inta jest
taki sam, nie zawsze będzie to int.
JD
A ja siďż˝ przyczepiďż˝.
Ciebie.
http://pl.wikipedia.org/wiki/Adopcja
http://pl.wikipedia.org/wiki/Adaptacja
j..
No to czepiaj si� p�ota. Akurat adopcja by�a jak najbardziej na miejscu
w tym znaczeniu. Interfejs zostaďż˝ adoptowany, a nie zaadaptowany.
Adaptacja oznacza�aby przystosowanie interfejsu, a nie w��czenie go w
takiej postaci, w jakiej jest. (inaczej w og�le ta operacja nie mia�aby
sensu).
--
\.\.\.\.\.\.\.\.\.\.\.\.\.\
.\.Kr...@epsilon.eu.org.\.\.
\.http://epsilon.eu.org/\.\
.\.\.\.\.\.\.\.\.\.\.\.\.\.
Przepraszam bardzo, czy owo "w��czenie interfejsu" to by�a zmiana
interfejsu istniej�cego ju� kodu?
Bo tylko wtedy u�ycie s�owa "adopcja" mog�oby mie� takie znaczenie,
jakie mu przypisujesz.
Zazwyczaj interfejs w��czasz do programu na zasadzie zupe�nie innej ni�
w��czasz dziecko do rodziny.
Dziecko ju� jest. Gdy zostaje w��czone do rodziny, jego wn�trze (cia�o)
si� nie zmienia, natomiast zostaje _zmieniony_ zapis zewn�trzny (zapis w
dokumentach).
Na zasadzie w�a�nie tej analogii istnieje poj�cie adopcji prawa (jakie�
prawo ju� jest, przyjmujemy tylko inny zapis - mo�liwe �e nios�cy inn�
tre��, gdy przyjdzie do jego stosowania), czy np. adopcji do rodu
szlacheckiego.
Odpowiada to zmianie interfejsu dla danego kodu.
_Do��czenie_ interfejsu (jako nast�pnego interfejsu do danego kodu) to
jest w�a�nie *do��czenie* i nie ma sensu u�ywanie w tym kontek�cie s�owa
"adopcja".
Natomiast gdy bierzesz kod wykonuj�cy jakie� zadanie, zostawiasz
interfejs nieruszonay, ale wn�trze kodu musisz dostosowa� do docelowaego
�rodowiska, to wtedy jest to oczywi�cie adaptacja, ale nie interfejsu,
tylko kodu.
Chyba, �e wyra�asz si� poetycko, wtedy przepraszam, na poezji wysokiego
lotu to ja siďż˝ nie znam.
j..
Rzeco? Gdyby by�a to zmiana interfejsu, to w�a�nie by�aby adaptacja.
>Zazwyczaj interfejs w��czasz do programu na zasadzie zupe�nie innej ni�
>w��czasz dziecko do rodziny.
>Dziecko ju� jest. Gdy zostaje w��czone do rodziny, jego wn�trze (cia�o)
>si� nie zmienia, natomiast zostaje _zmieniony_ zapis zewn�trzny (zapis w
>dokumentach).
Patrzysz z drugiej strony. Rodzina juďż˝ jest, natomiast zostaje
rozszerzona o obiekt dot�d obcy.
>Natomiast gdy bierzesz kod wykonuj�cy jakie� zadanie, zostawiasz
>interfejs nieruszonay, ale wn�trze kodu musisz dostosowa� do docelowaego
>�rodowiska, to wtedy jest to oczywi�cie adaptacja, ale nie interfejsu,
>tylko kodu.
Oczywi�cie. Kod trzeba adaptowa� do adoptowanego interfejsu.
--
[------------------------]
[ Kr...@epsilon.eu.org ]
[ http://epsilon.eu.org/ ]
[------------------------]
Chodzi�o mi o wymian� - jednego interfejsu na inny.
Przepraszam za brak precyzji.
Przy wyrzuceniu starego interfejsu by�aby to adaptacja kodu i adopcja
nowego interfejsu zarazem. O wyrzuceniu starego interfejsu nie
wspomnia�e� ni s�owem. A pisa�e� o adopcji interfejsu.
Adaptacja (czyli dostosowanie) interfejsu by�aby, gdyby dla danego kodu
wpowadza� zmiany istniej�cego interfejsu, aby kod np. m�g� dzia�a� w
innym �rodowisku.
No, ale ja widocznie patrzďż˝ z innej strony niďż˝ ty.
>
>> Zazwyczaj interfejs w��czasz do programu na zasadzie zupe�nie innej ni�
>> w��czasz dziecko do rodziny.
>> Dziecko ju� jest. Gdy zostaje w��czone do rodziny, jego wn�trze (cia�o)
>> si� nie zmienia, natomiast zostaje _zmieniony_ zapis zewn�trzny (zapis w
>> dokumentach).
>
> Patrzysz z drugiej strony. Rodzina juďż˝ jest, natomiast zostaje
> rozszerzona o obiekt dot�d obcy.
W�a�nie. Patrz� z innej strony.
Narodziny dziecka np. te� s� rozszerzeniem o obiekt dot�d obcy (w ko�cu
go nie by�o przedtem, prawda?), a nie nazwiesz tego adopcj�.
W tej analogii z prawa rodzinnego i cywilnego - czy nazwa�by� dziecko
interfejsem a prawa wynik�e z zaistnienia adopcji kodem, czy raczej
odwrotnie?
Ja patrzďż˝ na to tak:
Istniej�cy obiekt - dziecko, ma sw�j interfejs prawny - okre�lenie czyim
jest dzieckiem, po kim mo�e dziedziczy� itd.
Gdy zostaje adoptowane, ono samo siďż˝ nie zmienia - nadal ma tyle samo
r�k i n�g ile przed adopcj�, natomiast zostaje wymieniony (zazwyczaj
ca�kowicie) jego interfejs prawny - prawo do dziedziczenia, obowi�zki
alimentacyjne itp. siďż˝ zmieniajďż˝.
Tymczasem interfejs prawny dotychczasowych cz�onk�w mi�dzy nimi nie
zostaje wymieniony, tylko dostosowany - czyli adaptowany - do zmian
wynik�ych z adopcji dziecka.
>
>> Natomiast gdy bierzesz kod wykonuj�cy jakie� zadanie, zostawiasz
>> interfejs nieruszonay, ale wn�trze kodu musisz dostosowa� do docelowaego
>> �rodowiska, to wtedy jest to oczywi�cie adaptacja, ale nie interfejsu,
>> tylko kodu.
>
> Oczywi�cie. Kod trzeba adaptowa� do adoptowanego interfejsu.
Nie spos�b si� z tym nie zgodzi�.
j..
Zgadza si�. Gdyby�my mieli interfejs i dostosowywali go do istniej�cego
kodu, to by�aby adaptacja.
A IMHO nie trzeba wyrzuca� starego interfejsu �eby adoptowa� nowy. Mog�
funkcjonowa� r�wnolegle.
>>> Zazwyczaj interfejs w��czasz do programu na zasadzie zupe�nie innej ni�
>>> w��czasz dziecko do rodziny.
>>> Dziecko ju� jest. Gdy zostaje w��czone do rodziny, jego wn�trze (cia�o)
>>> si� nie zmienia, natomiast zostaje _zmieniony_ zapis zewn�trzny (zapis w
>>> dokumentach).
>> Patrzysz z drugiej strony. Rodzina juďż˝ jest, natomiast zostaje
>> rozszerzona o obiekt dot�d obcy.
>W�a�nie. Patrz� z innej strony.
>
>Narodziny dziecka np. te� s� rozszerzeniem o obiekt dot�d obcy (w ko�cu
>go nie by�o przedtem, prawda?), a nie nazwiesz tego adopcj�.
No, trochďż˝ inaczej siďż˝ to odbywa ;-)
>W tej analogii z prawa rodzinnego i cywilnego - czy nazwa�by� dziecko
>interfejsem a prawa wynik�e z zaistnienia adopcji kodem, czy raczej
>odwrotnie?
Analogie maj� swoje ograniczenia, ale je�eli dodajemy do istniej�cego
kodu interfejs, to jak najbardziej tu adoptujemy interfejs z punktu
widzenia kodu. Przecieďż˝ dziecko nie adoptuje siďż˝ samo do rodziny, tylko
ktoďż˝ je adoptuje, prawda?
>Ja patrzďż˝ na to tak:
>
>Istniej�cy obiekt - dziecko, ma sw�j interfejs prawny - okre�lenie czyim
>jest dzieckiem, po kim mo�e dziedziczy� itd.
>Gdy zostaje adoptowane, ono samo siďż˝ nie zmienia - nadal ma tyle samo
>r�k i n�g ile przed adopcj�, natomiast zostaje wymieniony (zazwyczaj
>ca�kowicie) jego interfejs prawny - prawo do dziedziczenia, obowi�zki
>alimentacyjne itp. siďż˝ zmieniajďż˝.
Oj, za daleko brniesz w tďż˝ analogiďż˝, MSZ.
>>> Natomiast gdy bierzesz kod wykonuj�cy jakie� zadanie, zostawiasz
>>> interfejs nieruszonay, ale wn�trze kodu musisz dostosowa� do docelowaego
>>> �rodowiska, to wtedy jest to oczywi�cie adaptacja, ale nie interfejsu,
>>> tylko kodu.
>> Oczywi�cie. Kod trzeba adaptowa� do adoptowanego interfejsu.
>Nie spos�b si� z tym nie zgodzi�.
I na tym chyba zako�czymy :-)
> A IMHO nie trzeba wyrzuca� starego interfejsu �eby adoptowa� nowy. Mog�
> funkcjonowa� r�wnolegle.
>
>>>> Zazwyczaj interfejs w��czasz do programu na zasadzie zupe�nie innej ni�
>>>> w��czasz dziecko do rodziny.
>>>> Dziecko ju� jest. Gdy zostaje w��czone do rodziny, jego wn�trze (cia�o)
>>>> si� nie zmienia, natomiast zostaje _zmieniony_ zapis zewn�trzny (zapis w
>>>> dokumentach).
>>> Patrzysz z drugiej strony. Rodzina juďż˝ jest, natomiast zostaje
>>> rozszerzona o obiekt dot�d obcy.
>> W�a�nie. Patrz� z innej strony.
>>
>> Narodziny dziecka np. te� s� rozszerzeniem o obiekt dot�d obcy (w ko�cu
>> go nie by�o przedtem, prawda?), a nie nazwiesz tego adopcj�.
>
> No, trochďż˝ inaczej siďż˝ to odbywa ;-)
Wiem coďż˝ o tym, jednak to tylko analogia.
Pewne szczeg�y b�d� si� r�ni�.
>
>> W tej analogii z prawa rodzinnego i cywilnego - czy nazwa�by� dziecko
>> interfejsem a prawa wynik�e z zaistnienia adopcji kodem, czy raczej
>> odwrotnie?
>
> Analogie maj� swoje ograniczenia, ale je�eli dodajemy do istniej�cego
> kodu interfejs, to jak najbardziej tu adoptujemy interfejs z punktu
> widzenia kodu. Przecieďż˝ dziecko nie adoptuje siďż˝ samo do rodziny, tylko
> ktoďż˝ je adoptuje, prawda?
>
>> Ja patrzďż˝ na to tak:
>>
>> Istniej�cy obiekt - dziecko, ma sw�j interfejs prawny - okre�lenie czyim
>> jest dzieckiem, po kim mo�e dziedziczy� itd.
>> Gdy zostaje adoptowane, ono samo siďż˝ nie zmienia - nadal ma tyle samo
>> r�k i n�g ile przed adopcj�, natomiast zostaje wymieniony (zazwyczaj
>> ca�kowicie) jego interfejs prawny - prawo do dziedziczenia, obowi�zki
>> alimentacyjne itp. siďż˝ zmieniajďż˝.
>
> Oj, za daleko brniesz w tďż˝ analogiďż˝, MSZ.
Hmmm... sam zacz��e� wchodzi� w w�tpliwe analogie u�ywaj�c s�owa "adopcja".
>
>>>> Natomiast gdy bierzesz kod wykonuj�cy jakie� zadanie, zostawiasz
>>>> interfejs nieruszonay, ale wn�trze kodu musisz dostosowa� do docelowaego
>>>> �rodowiska, to wtedy jest to oczywi�cie adaptacja, ale nie interfejsu,
>>>> tylko kodu.
>>> Oczywi�cie. Kod trzeba adaptowa� do adoptowanego interfejsu.
>> Nie spos�b si� z tym nie zgodzi�.
>
> I na tym chyba zako�czymy :-)
>
My�l�, �e jednak podsumowanie w wykonaniu funkcji sieciowej (patrz
wczorajszy post tej osoby) jest najtrafniejsze.
Zatem "w tym temacie" z mojej strony juďż˝ EOT.
j..
API gniazd w POSIXie jest całkiem naturalne po chwili praktyki. Musisz
pamiętać, że jest to interfejs C, a nie Java/Python/Ruby, i odwołuje
się w
zasadzie bezpośrednio do OSa (praktycznie wszystkie operacje na
gniazdach
to owinięte wywołania systemowe). Z tej perspektywy interfejs jest
całkiem
niezły.
Twoje narzekanie natomiast dotyczy głównie WinAPI. Tego API komentować
nie będę, bo gniazda nie są jedynym miejscem w którym "z lekka
odstaje".
Jeśli natomiast chcesz czegoś wysokopoziomowego, to użyj jednego
z pierdyliarda zrębów do programowania sieci, od boost::asio do
withSocketsDo.
pozdro
--
Michał 'Khorne' Rzechonek