2013-03-23 13 views
8

Nel mio codice, ho I/O asincrono con I/O Completion Ports e, per il completamento di lettura/scrittura , ottengo un HANDLE (che ovviamente può essere un socket, un handle di file, named pipe e così via). Quindi se qualcosa non va in questa routine, voglio controllare l'errore, ma come sapere se è una "rete" HANDLE [un SOCKET, quindi dovrei chiamare WSAGetLastError()] o un "non-network" HANDLE [chiamato pipe, file e così via, quindi dovrei chiamare GetLastError()]? Sto usando una semplice bandiera per questo, ma è brutta e insopportabile. Se qualcuno può confermare che WSAGetLastError() è solo un alias per GetLastError(), userò solo quest'ultimo.WSAGetLastError() è solo un alias per GetLastError()?

Sembra così:

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

Ma qualcuno può confermare che? MSDN non è molto chiaro su questo argomento.

E: sarebbe sicuro utilizzare GetLastError() anziché WSAGetLastError()? Voglio dire, se WSAGetLastError() è anche un alias di GetLastError() dal momento che Windows95 come affermano qualcuno, posso presumere che sarà vero per la prossima versione di Windows - ma non possiamo scrivere un buon codice sull'assunzione di cose :)

risposta

9

È solo un wrapper di GetLastError se si esegue il reverse engineering ws2_32.dll, lo troverete.

+0

Sì, l'ho visto, ma si utilizzerà GetLastError() anziché WSAGetLastError()? Non credo che separeranno queste 2 funzioni, ormai –

+1

Penso che sia più sicuro utilizzare WSAGetLastError a causa di errori specifici di Winsock. Ma questa è solo la mia opinione. – Xearinox

+1

È più pulito utilizzare la funzione suggerita dalla documentazione, tuttavia in questo caso particolare è altamente improbabile che questi due si interromperanno mai in funzioni separate. –

5

ragione di avere due funzioni simili: http://blogs.msdn.com/b/oldnewthing/archive/2005/09/08/462402.aspx

Perché la funzione WSASetLastError esiste quando v'è già la perfetta buona funzione SetLastError?

In realtà, anche tu sai la risposta, se ti siedi e ci pensi.

Winsock è stato originariamente sviluppato per essere eseguito su Windows a 16 bit e Windows a 32 bit. Si noti come le funzioni Winsock classiche si basano sui messaggi di finestra per le notifiche asincrone. Nel mondo a 16 bit, non esisteva la funzione SetLastError. Pertanto, Winsock doveva fornire la propria versione per l'implementazione a 16 bit. E poiché la compatibilità del codice sorgente è importante, c'era anche una versione a 32 bit. Naturalmente, la versione a 32 bit sembra abbastanza stupida in retrospettiva se non si è a conoscenza della versione a 16 bit.

Problemi correlati