CString char/wchar_t conflict

CString char/wchar_t conflict

• KenBaker

  Are you able to reproduce this behavior in a simple project (like a single file console app) If not, perhaps you've got a floating _UNICODE define somewhere.
  
  

• Gamb

  Any code that calls into CSimpleStringT will have this issue for me.
  
  CString str;
  str = _T("Whatever");
  int len = str.GetLength();
  
  If I put a breakpoint on that last line, the debugger shows str as having char traits. When I step into GetLength(), however, the debugger shows str as having wchar_t traits and the data looks like garbage. If, at the CSimpleStringT level, I cast the m_pszData to a char* in the Watch window, it looks fine.
  
  So (in the Watch window inside the CSimpleStringT::GetLength() call):
  m_pszData = 0x00398078 "????????????????????????????"
  (char*)m_pszData = 0x00398078 "Whatever"
  
  
  Any call to GetLength() will return 0 because at that level, the data is wchar_t (or so it appears in the debugger).
  
  Also, if I add a line:
  int len2 = _tcslen(str);
  
  The above line WILL resolve to strlen, so obviously _UNICODE is not defined. I seem to be in a weird dual state where CSimpleStringT thinks it has wchar_t traits, but CStringT has char traits.
  
  

• sgudavalli

  Is ist just a debugging issue, or is there any missbehaviour in the code

  If so, show us some code!

  
  
  

• mklee

  Martin, I tried reproducing this based on your bug report. I assumed the use of #include <atlstr.h> (you didn't specify the header in your steps.)  Here's my console app code (I turned off pch).

  #include <atlstr.h>
  int main()
  {
  CString str;
  str = _T("Whatever");
  int len = str.GetLength();
  return 0;
  }

  I'm compiling without _UNICODE and UNICODE, and with _MBCS.  When stepping into GetLength(), the debugger shows the function as ATL::CSimpleStringT<char,0> in the call stack.  The return value is 8, which is expected.

  Perhaps the repro steps need to be more specific, in either in terms of what the code/build settings are, or what exactly one should be looking for in the debugger

  Brian

   

  
  

• Devcom

  Use this:

  CString str;

  str = _T("Whatever");

  int len = str.GetLength() * sizeof(wchar_t);

  I hope this will solve your problem.

  Nishith

  
  

• JLuis

  Yes I see the same behaviour in the debugger in VS2005.

  I placed a bug report:

  http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=b6467baa-5a84-4bf1-9989-923aba417eff

  
  
  

• GavinWu

  I'm not sure if this thread is still active - if not, I'll start another one.
  
  But this issue is cropping up again. This is at a different company; so different machine, different codebase, etc.
  
  I posted a picture here
  
  As you can see, "m_reply" is a wchar_t CString (this is a Unicode app). But as the code goes into GetLength(), somehow the character traits are now char. Really strange, as you can also see that the code is stepping into the Unicode MFC dll!
  
  m_reply.GetLength() returns 14.
  _tcslen(m_reply) returns 4.
  
  I can get around this issue by just using _tcslen everywhere, but there are GetLength() calls all through the code. I also wonder if such issues are causes by converting a MBCS codebase to Unicode (which was the case here and at my previous job when I made the first post).
  
  

• Ramadan

  @Nishith_Sheth

  Its not about the result. Its about the display of the variables in the debugger! The code runs correct as expected!

  
  
  

• Guy C.

  I just checked it with an MFC project.

  The returnvalue is always OK! The problem is when you step into the debugger! It sometimes shows that the CString is a wchar_t* but in fact its char*!

  I am in hurry! But I will take a look at my report. But as I see they have a repro for it! Status is validated!

  
  
  
• CString char/wchar_t conflict