2013-03-23 6 views
8

W moim kodzie mam asynchroniczne operacje we/wy z portami wejścia/wyjścia, a dla wywołań zwrotnych zakończenia odczytu/zapisu otrzymuję UCHWYT (to oczywiście może być gniazdo, uchwyt pliku, nazwany potok i tak dalej). Więc jeśli coś jest nie tak w takiej rutynie, chcę sprawdzić błąd, ale jak sprawdzić, czy jest to "sieć" HANDLE [a SOCKET, więc powinienem nazwać WSAGetLastError()] lub "NIE-sieci" RĘKĘ [o nazwie potoki, pliki i tak dalej, więc powinienem nazwać GetLastError()]? Używam do tego prostej flagi, ale jest to brzydkie i niewspółmierne. Jeśli ktoś może potwierdzić, że WSAGetLastError() jest tylko aliasem dla GetLastError(), użyję tylko tego drugiego.Czy WSAGetLastError() jest tylko aliasem dla GetLastError()?

Wydaje się więc:

http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.networks/2007-08/msg00034.html

http://us.generation-nt.com/wsagetlasterror-just-an-alias-getlasterror-help-28256642.html

Ale może ktoś potwierdzić? MSDN nie ma zbyt wiele na ten temat.

I: byłby bezpieczny używać GetLastError() zamiast WSAGetLastError()? Mam na myśli, jeśli WSAGetLastError() jest nawet aliasem GetLastError() od Windows 95, jak twierdzą ktoś, mogę założyć, że będzie to prawda dla następnej wersji systemu Windows - ale nie możemy napisać dobrego kodu zakładając rzeczy :)

Odpowiedz

9

To jest po prostu wrapper do GetLastError, jeśli cofniesz inżynierię ws2_32.dll, znajdziesz ją.

+0

Tak, widziałem to, ale czy użyłbyś GetLastError() zamiast WSAGetLastError()? Nie sądzę, że będą one oddzielić te 2 funkcje, teraz –

+1

Myślę, że jest bezpieczniejsze użycie WSAGetLastError z powodu konkretnych błędów Winsock. Ale to tylko moja opinia. – Xearinox

+1

Jest to bardziej przejrzyste w użyciu funkcji sugerowanej w dokumentacji, jednak w tym szczególnym przypadku jest bardzo mało prawdopodobne, że te dwa kiedykolwiek podzielą się na osobne funkcje. –

5

powodem posiadające dwa podobne funkcje: http://blogs.msdn.com/b/oldnewthing/archive/2005/09/08/462402.aspx

Dlaczego WSASetLastError funkcja istnieje, gdy nie jest już doskonale dobra funkcja SetLastError?

Właściwie znasz też odpowiedź, jeśli usiądziesz i pomyślisz o tym.

Oprogramowanie Winsock zostało pierwotnie opracowane do pracy zarówno w 16-bitowym systemie Windows, jak i 32-bitowym systemie Windows. Zwróć uwagę, że klasyczne funkcje Winsock są oparte na komunikatach okien dotyczących powiadomień asynchronicznych. W 16-bitowym świecie nie było funkcji SetLastError. Dlatego Winsock musiał dostarczyć własną wersję dla 16-bitowej implementacji. A ponieważ zgodność kodu źródłowego jest ważna, istniała również wersja 32-bitowa. Oczywiście wersja 32-bitowa wygląda na głupią z perspektywy czasu, jeśli nie jesteście świadomi wersji 16-bitowej.