title: Casting string type with GetDlgItemText() for use as string buffer in C++
body: <p>I am stumped by the behaviour of the following in my Win32 (ANSI) function:
  (Multi-Byte Character Set NOT UNICODE) </p>
  
  <pre><code>void sOut( HWND hwnd, string sText ) // Add new text to EDIT Control
  { 
   int len;
   string sBuf, sDisplay;
  
    len = GetWindowTextLength( GetDlgItem(hwnd, IDC_EDIT_RESULTS) ); 
    if(len &gt; 0)
    {
     // HERE:
     sBuf.resize(len+1, 0); // Create a string big enough for the data
     GetDlgItemText( hwnd, IDC_EDIT_RESULTS, (LPSTR)sBuf.data(), len+1 );
    } // MessageBox(hwnd, (LPSTR)sBuf.c_str(), "Debug", MB_OK);
  
    sDisplay = sBuf + sText;
    sDisplay = sDisplay + "\n\0"; // terminate the string
    SetDlgItemText( hwnd, IDC_EDIT_RESULTS, (LPSTR)sDisplay.c_str() );
  } 
  </code></pre>
  
  <p>This should append text to the control with each call.</p>
  
  <p>Instead, all string concatenation fails after the call to <code>GetDlgItemText()</code>, I am assuming because of the typecast?</p>
  
  <p>I have used three string variables to make it really obvious. If <code>sBuf</code> is affected then sDisplay should not be affected.</p>
  
  <p>(Also, why is len 1 char less than the length in the buffer?)</p>
  
  <p><code>GetDlgItemText()</code> corretly returns the content of the EDIT control, and SetDlgItemText() will correctly set any text in <code>sDisplay</code>, but the concatenation in between is just not happening.</p>
  
  <p>Is this a "hidden feature" of the string class?</p>
  
  <p><strong>Added:</strong></p>
  
  <p>Yes it looks like the problem is a terminating NUL in the middle. Now I understand why the len +1. The function ensures the last char is a NUL. </p>
  
  <p>Using <code>sBuf.resize(len);</code> will chop it off and all is good. </p>
  
  <p><strong>Added:</strong></p>
  
  <p>Charles, </p>
  
  <p>Leaving aside the quirky return length of this particular function, and talking about using a string as a buffer:</p>
  
  <blockquote>
    <p>The standard describes the return value of basic_string::data() to be a pointer to an array whose members equal the elements of the string itself. </p>
  </blockquote>
  
  <p>That's precisely what's needed isn't it?</p>
  
  <blockquote>
    <p>Further, it requires that the program must not alter any of the values of that array. </p>
  </blockquote>
  
  <p>As I understand it that is going to change along with the guarantee that all bytes are contiguous. I forget where I read a long article on this, but MS already implements this it asserted.</p>
  
  <p>What I don't like about using a vector is that the bytes are copied twice before I can return them: once into the vector and again into the string. I also need to instantiate a vector object and a string object. That is a lot of overhead. If there were some string friendly of working with vectors (or CStrings) without resorting to old C functions or sopying characters one by one, I would use them. The string is very syntax friendly in that way.</p>