Click here to Skip to main content
       

ATL / WTL / STL

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
QuestionCAsyncSocket Send( arguments ) [modified]memberbkelly1318 Sep '12 - 16:13 
Windows 7, Visual Studio 2008, MFC, C++
 
Intellisense says the arguments for this method are:
 
Send( const void *lpBuf, int nBufLen, int Flasg = 0 )
An MSDN web page has example code that looks like this:
 
Send((LPCTSTR)m_sendBuffer + m_nBytesSent, 
         m_nBytesBufferSize - m_nBytesSent);

 
Either way, I cannot get the right combination. I have:
 
SYSTEMTIME m_current_time;
GetSystemTime( &m_current_time );
int t1 = sizeof( m_current_time );
int chars_sent = m_C_Server_Send_Time_Socket->Send( (LPCTSTR) m_current_time, t1,   0 );
Where m_C_Server_Send_Time_Socket is the object created from CAsyncSocket to do all the transactions once the connection has been established.
 
How should the arguments to Send() be written?
Thanks for your time


modified 18 Sep '12 - 22:50.

AnswerRe: CAsyncSocket Send( arguments )mvpRichard MacCutchan18 Sep '12 - 21:50 
bkelly13 wrote:
How should the arguments to Send() be written?
As described in the documentation[^] is usually the right way. In your case why would you cast to LPCTSTR when it specifically states to cast to const void*? So your code should look like:
int chars_sent = m_C_Server_Send_Time_Socket->Send((const void*)&m_current_time, t1,   0 );
Maybe a bit of a refresher about casts, pointers and the addressof operator would be useful.
One of these days I'm going to think of a really clever signature.

GeneralRe: CAsyncSocket Send( arguments )memberbkelly1319 Sep '12 - 12:13 
I am sure I tried that. I probably had a typo and did not recognize it.
Thank you for taking the time to reply.
Thanks for your time

AnswerRe: CAsyncSocket Send( arguments )memberpasztorpisti29 Sep '12 - 23:52 
Here is the thing: In C/C++ every pointer is automatically casted into (const void*) and every non-const pointer is automatically casted into (void*). The msdn web page used cast just because of the pointer arithmetic involved, as you see they add an integer value to the start of the buffer: (LPCTSTR)m_sendBuffer + m_nBytesSent. They cast the buffer pointer into LPCTSTR because they want the addition to step the pointer with *byte* granularity. The problem with this is that LPCTSTR can translate not only to (const char*) but also into (const wchar_t*) (when the project character set is unicode, and note that wchar_t is a type whose size is 2 bytes!) so I guess MS guys made a mistake here and (LPCTSTR) is a bug (if the project character setting is set the unicode), they should have used (char*) or its equivalent in winodws: LPSTR or const char* or LPCSTR or something like that, something that is a *byte* pointer. Your problem is that you try to convert an instance of your struct into a pointer. You can not convert an instance into a pointer! You can converty only a pointer into a different type of pointer and in rare cases conversion might be needed between pointer and integral types.
SYSTEMTIME m_current_time;
GetSystemTime( &m_current_time );
int t1 = sizeof( m_current_time );
// This is the case where you try to convert your instance into a pointer incorrectly:
int chars_sent = m_C_Server_Send_Time_Socket->Send( (LPCTSTR) m_current_time, t1,   0 );
// Here is the correct way to do that:
int chars_sent = m_C_Server_Send_Time_Socket->Send( (LPCTSTR) &m_current_time, t1,   0 );
// Note that every pointer can be converted into (const void*)
//  so the cast is totally unnecessary and you can write simply:
int chars_sent = m_C_Server_Send_Time_Socket->Send( &m_current_time, t1, 0 );
Note that using (LPCTSTR) is a bug even on microsoft's side! You need to convert your struct pointer into a (char*) only if you want to step your pointer with byte precision!
SYSTEMTIME m_current_time;
 
// The following steps the pointer with sizeof(SYSTEMTIME) bytes in memory!!!!!
// The resulting pointer points to the first byte that follows the last byte of your struct.
SYSTEMTIME* p = &m_current_time + 1;
 
//Since pointers and arrays in C/C++ work very similarly the above code is identical to this:
SYSTEMTIME* p = &(&m_current_time)[1];
//Pointer arithmetic and array indexing behave very similarly.

// The following expressions step the pointer just by 1 byte (sizeof(char)) in memory!!!!!
// We basically index into our struct as if it was a byte array...
// This is what MS guys wanted to do but in some cases (with unicode character setting)
// their code steps the pointer with 2 byte granularity (sizeof(whcar_t)) that is a bug.
char* p = (char*)&m_current_time + 1;
 
// The statements below are also valid because <code>char*</code> (like any other non-const
// pointer) is automatically casted to both <code>void*</code> and <code>const void*</code>.
void* p = (char*)&m_current_time + 1;
const void* p = (char*)&m_current_time + 1;
Note that an addition or a substraction on a pointer always steps the pointer with the size of the type the pointer points to (like when you indexing into an array of the specified type). For this reason you can not step void pointers without casting them into something else - the size of void isn't defined.
GeneralRe: CAsyncSocket Send( arguments )mvpRichard MacCutchan30 Sep '12 - 1:07 
But using LPCTSTR ensures that the pointer is incremented by the number of characters (whether Unicode or ASCII) not the number of bytes, so Microsoft are doing it right.
One of these days I'm going to think of a really clever signature.

GeneralRe: CAsyncSocket Send( arguments )memberpasztorpisti30 Sep '12 - 3:16 
If we speak of unicode and wchar_t then its not guaranteed that the data is transferred per character over the network, the variable name they use for incrmenting also reflects this: m_nBytesSent. They code heavily relies on the fact that LPCTSTR==LPCSTR in their case. Changing to unicode charset would introduce a hidden bug that compiles silently. If you decide to write code that has to compile with both ansi and widechar setting then using LPCTSTR is valid in many cases but this is an exception. I myself question the usefulness of supporting both ansi and widechar these days (so I don't anymore use defines like LPCTSTR and LPSTR) since its pain in the ass to write a program that compiles with both settings and today we can say that the majority of machines runs NT whose native is utf16. Its also a pain to search for bugs that arise only with one of the settings.
GeneralRe: CAsyncSocket Send( arguments )mvpRichard MacCutchan30 Sep '12 - 4:00 
You are quite right, I failed to read that in enough detail; my apologies. I should know better than to challenge your knowledge.
One of these days I'm going to think of a really clever signature.

GeneralRe: CAsyncSocket Send( arguments )memberpasztorpisti30 Sep '12 - 4:07 
Your comment is quite okay, this is a place for technical debates. I'm open to challenges anyway. Smile | :)
GeneralRe: CAsyncSocket Send( arguments )memberpasztorpisti30 Sep '12 - 4:03 
I searched for their code and I guess I found the codepiece OP is talking about: http://msdn.microsoft.com/en-us/library/aa268613%28v=vs.60%29.aspx[^]
They are using ansi string literals (without TEXT macro) so their code wouldn't compile with uncode charset, for this reason I guess they haven't tried this code with unicode setting so the bug could easily hide there.
GeneralRe: CAsyncSocket Send( arguments )mvpRichard MacCutchan30 Sep '12 - 4:13 
Yes, it is rather a poor example.
One of these days I'm going to think of a really clever signature.

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   


Advertise | Privacy | Mobile
Web04 | 2.6.130523.1 | Last Updated 21 May 2013
Copyright © CodeProject, 1999-2013
All Rights Reserved. Terms of Use
Layout: fixed | fluid