I have tried to use an std::set<std::wstring>, and the debugger appears to have a problem with displaying the values that are stored in the set (this also happens when using std::wstring as the key value in a map.
Sample code:
#include
<set>#include
<string>int
main(){
std::set<std::wstring> test;
test.insert( L
"1234567" ); // this is displaying correctly in the watch window test.insert( L"12345678" ); // this is displaying garbage in the watch window return 0;}
This isn't a major problem, but makes it more difficult to use std::wstring.
John

The debugger isn't displaying std::wstring values
leovernazza
I submitted this as bug FDBK50701.
John
Peter Sarrett
This is not necessarily a bug. This is a side-effect of the small string optimization that string and wstring use. If you look in xstring you'll see the following code in the definition of basic_string:
union _Bxty{ // storage for small buffer or pointer to larger one
_Elem _Buf[_BUF_SIZE];
_Elem *_Ptr;
} _Bx;
So strings that are <= _BUF_SIZE are stored 'inline' in the array while strings that are > _BUF_SIZE have their own memory.
The debugger shows the first field of the union so for small strings you see the string while for longer strings you see the address of the memory that holds the string.
Though I thought that autoexp.dat was fixed to handle this correctly: which version of the product are you using
riet
Hi Jonathan,
Thanks for looking into this further. I looked at the autoexp.dat file on my system and it does have slightly different contents in the section under children for both std::basic_string types. Both versions have the following for the children section:
children
(
#if(($e._Myres) < ($e._BUF_SIZE))
(
#([actual members]: [$e,!] , #array( expr: $e._Bx._Buf[$i], size: $e._Mysize))
)
#else
(
#([actual members]: [$e,!], #array( expr: $e._Bx._Ptr[$i], size: $e._Mysize))
)
)
I saved off a copy (for reference) and then replaced this section with the text that you posted. After restarting the studio, it still is showing the same results.
As an experiment, I then tried the following:
It doesn’t look like my studio is using the autoexp.dat file that I edited.
I searched my disk to see if there were any other autoexp.dat files, and the only other one I found was in the VC 6.0 installation in a different location.
There are a few details here that may be use:
Best regards,
John
Pentalon
Please log the issue at http://lab.msdn.microsoft.com/productfeedback/default.aspx
Thanks in advance for taking the time to report the issue!
Thanks, Ayman Shoukry VC++ Teamnumbers65
Hi Jonathan,
I would call this a bug, as it works correctly when I use std::string instead of std::wstring. How can displaying the wrong values in one case and the right values in another case be considered a side-effect It makes it difficult to use wstring with set or map, as I need to expand the array to see individual characters when it is a long string.
In answer to your question: as far as I know, we are using the release version of the Team Edition. The about box shows Version 8.0.50727.42 (RTM.050727-4200), with version 77642-113-2000004-41990 for Visual C++ 2005.
If you know of a change I can make to autoexp.dat, it would be useful. It isn't really a bug that affects us much, as most of the code we have uses multi-byte character sets instead of wide, but it just makes debugging a small number of programs more tedious.
John
john ewing
Hi Jonathan,
I have tracked down the condition that makes this happen. The project that I have been using is being compiled with the /clr option. It is part of a larger program that is using some managed code and needs to have this set.
When a make a new test program that doesn't use the /clr option, the wstring values all display properly in the debugger and the custom strings that I added to autoexp.dat are used. When I turn on the /clr option, the debugger doesn't appear to use the autoexp.dat file anymore and the wstring values don't display properly.
Is there a different way to configure the debugger for displaying wstring values when using /clr option
Best regards,
John
Maya__
I've been playing around with this a bit and so far I haven't been able to reproduce the failure you are seeing: so I suspect that the problem might be with your version of autoexp.dat. The version of autoexp.dat that I have (which lives in Visual Studio 2005\common7\packages\debugger) contains the following 'instructions' for displaying a string:
std::basic_string<char,*>{
preview
(
#if(($e._Myres) < ($e._BUF_SIZE))
(
[$e._Bx._Buf,s]
)
#else
(
[$e._Bx._Ptr,s]
)
)
stringview
(
#if(($e._Myres) < ($e._BUF_SIZE))
(
[$e._Bx._Buf,sb]
)
#else
(
[$e._Bx._Ptr,sb]
)
)
children
(
#if(($e._Myres) < ($e._BUF_SIZE))
(
#([actual members]: [$e,!] ,[fixed buffer]: $e._Bx._Buf)
)
#else
(
#([actual members]: [$e,!], [dynamic buffer]: $e._Bx._Ptr)
)
)
}
std::basic_string<unsigned short,*>|std::basic_string<wchar_t,*>{
preview
(
#if(($e._Myres) < ($e._BUF_SIZE)) ( [$e._Bx._Buf,su] )
#else ( [$e._Bx._Ptr,su] )
)
stringview
(
#if(($e._Myres) < ($e._BUF_SIZE)) ( [$e._Bx._Buf,sub] )
#else ( [$e._Bx._Ptr,sub] )
)
children
(
#if(($e._Myres) < ($e._BUF_SIZE))
(
#([actual members]: [$e,!] ,fixed buffer: $e._Bx._Buf)
)
#else
(
#([actual members]: [$e,!], dynamic buffer: $e._Bx._Ptr)
)
)
}