Win-Sockets / Unicode
-
Hi, I've again a question about winsockets. How do I manage sending data, if I have e.g. TCHARs at my client side ? Do I have to convert my TCHAR strings at clientside to normal char strings, then send them, and then convert them at server side back to TCHARs ? Or is there a better way to do this ? For information: I am writing a little protocol, so there are also Integers in my sending buffer...maybe this complicates the thing a little bit, I don't really know.
-
Hi, I've again a question about winsockets. How do I manage sending data, if I have e.g. TCHARs at my client side ? Do I have to convert my TCHAR strings at clientside to normal char strings, then send them, and then convert them at server side back to TCHARs ? Or is there a better way to do this ? For information: I am writing a little protocol, so there are also Integers in my sending buffer...maybe this complicates the thing a little bit, I don't really know.
Sockets know nothing about the data you are sending. It's all just bytes at the socket level. The only trick is to make sure you calculate BYTE counts and not TCHAR counts. In other words, don't use _tcslen()....use _tcslen() * sizeof(TCHAR) (of course, add 1 to _tcslen() for the NULL terminator if that's being sent).
-
Sockets know nothing about the data you are sending. It's all just bytes at the socket level. The only trick is to make sure you calculate BYTE counts and not TCHAR counts. In other words, don't use _tcslen()....use _tcslen() * sizeof(TCHAR) (of course, add 1 to _tcslen() for the NULL terminator if that's being sent).
Hey thanks. I've now done this at the sending client to copy the TCHARs to my sending buffer: memcpy(pPointerToBuffer,MyString,wcslen(MyString)*sizeof(TCHAR)) And at the server side I do something like this: int n = 10; //assuming that we know that this unicode string has a length of 10 TCHAR ReceivedString[n]; memcpy(ReceivedString,pPointerToBuffer,sizeof(TCHAR)*10); ... This works and I think it's correct. Or is there a better way to do this ? Again thank you
-
Hey thanks. I've now done this at the sending client to copy the TCHARs to my sending buffer: memcpy(pPointerToBuffer,MyString,wcslen(MyString)*sizeof(TCHAR)) And at the server side I do something like this: int n = 10; //assuming that we know that this unicode string has a length of 10 TCHAR ReceivedString[n]; memcpy(ReceivedString,pPointerToBuffer,sizeof(TCHAR)*10); ... This works and I think it's correct. Or is there a better way to do this ? Again thank you
You need to make sure that your client and server both agree on what a
TCHARis. They both need to be compiled for UNICODE, or they both need to be compiled for ANSI.
Software Zen:
delete this; -
Hey thanks. I've now done this at the sending client to copy the TCHARs to my sending buffer: memcpy(pPointerToBuffer,MyString,wcslen(MyString)*sizeof(TCHAR)) And at the server side I do something like this: int n = 10; //assuming that we know that this unicode string has a length of 10 TCHAR ReceivedString[n]; memcpy(ReceivedString,pPointerToBuffer,sizeof(TCHAR)*10); ... This works and I think it's correct. Or is there a better way to do this ? Again thank you
In addition to Gary Wheeler's response.. This line memcpy(pPointerToBuffer,MyString,wcslen(MyString)*sizeof(TCHAR)) IMO could be confusing. wcslen() is for wchar_t types only, but TCHAR is generic and its type depends on whether UNICODE is defined or not. For code that could potentially be compiled with OR without UNICODE then I'd recommend using all generics: // All generics memcpy(pPointerToBuffer,MyString,_tcslen(MyString)*sizeof(TCHAR)) For code that will always be UNICODE compiled, use: // All wchar_t memcpy(pPointerToBuffer,MyString,wcslen(MyString)*sizeof(wchar_t)) Whatever is best for your situation - the point is consistency (makes it easier to prevent or track down bugs later :)). As stated by Mr Wheeler, both ends will need to know the character type. That can be exchanged in initial handshake between peers or it could be assumed (always the same). Both are fine - it's a matter of what you need. Along the same lines, you mentioned you have int or DWORD values you send as well. If you know the CPU on both ends will always store "int"s in little-endian format then you can just send them as a byte stream (byte count = sizeof(int)). If there's a chance the peers will use different byte ordering then you'll want to convert them to network byte order (or whatever scheme you choose to use) so that both ends will always be able to put an int back together in the proper order. All that aside, your code is fine for Unicode strings :)
-
In addition to Gary Wheeler's response.. This line memcpy(pPointerToBuffer,MyString,wcslen(MyString)*sizeof(TCHAR)) IMO could be confusing. wcslen() is for wchar_t types only, but TCHAR is generic and its type depends on whether UNICODE is defined or not. For code that could potentially be compiled with OR without UNICODE then I'd recommend using all generics: // All generics memcpy(pPointerToBuffer,MyString,_tcslen(MyString)*sizeof(TCHAR)) For code that will always be UNICODE compiled, use: // All wchar_t memcpy(pPointerToBuffer,MyString,wcslen(MyString)*sizeof(wchar_t)) Whatever is best for your situation - the point is consistency (makes it easier to prevent or track down bugs later :)). As stated by Mr Wheeler, both ends will need to know the character type. That can be exchanged in initial handshake between peers or it could be assumed (always the same). Both are fine - it's a matter of what you need. Along the same lines, you mentioned you have int or DWORD values you send as well. If you know the CPU on both ends will always store "int"s in little-endian format then you can just send them as a byte stream (byte count = sizeof(int)). If there's a chance the peers will use different byte ordering then you'll want to convert them to network byte order (or whatever scheme you choose to use) so that both ends will always be able to put an int back together in the proper order. All that aside, your code is fine for Unicode strings :)
Hey, thanks a lot. Now it's all clear to me. (sry for late reply)