Visual C++ 2010 refuses to show std::string value

Question

I have a strange feeling like this is a recent issue and happens on two separate computers.

When I'm debugging and trying to look at the value of an std::string from STL, it shows as the value. It says its size is 15 and capacity is some garbled huge number.

The array values themselves all say CXX0030: Error: expressions cannot be evaluated.

This is extremely frustrating and I can still access the string values while debugging if I call c_str on the string and assign it to a char * or use watch expressions if I need to, but it's very tedious and makes life very hard when debugging complicated problems for 3 days straight.

The contents other STL containers show up just fine.

This happens on multiple projects on two different computers, and I'm pretty sure I have all debugging options set for the project. No optimizations, and generating debugging info for sure.

Answer 1

Had the same problem and fixed it by changing the visualizer in autoexp.dat. It's found here: "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\autoexp.dat" or somewhere similar depending on your Visual Studio and Windows version.

Changes for "std::basic_string":

replace $e._BUF_SIZE

by sizeof($e._Bx._Buf)/sizeof(char)

or sizeof($e._Bx._Buf)/sizeof(wchar_t)

https://connect.microsoft.com/VisualStudio/feedback/details/677683/std-string-incorrectly-displayed-in-debugger

Answer 2

Sounds like the small string optimization at work. VS2010 does so up to 16 characters. In that case, there's no pointer to the begin of string, nor a capacity member, but instead those bytes are used for the string contents itself.

Answer 3

This might be an instance of a Microsoft-confirmed bug (unfortunately, not fixed in VS2010) related to custom iterator debugging level. I have just bumped into this myself, and, as far as my tests show, this bug is caused by defining _HAS_ITERATOR_DEBUGGING=0 while using the default "Multithreaded Debug DLL" runtime (the one requiring VC redist to run your exe on other PCs).

If that is really the case, then there are at least 2 ways of fixing it (short of upgrading to VS2012) - both tested and working in my case:

1) Remove _HAS_ITERATOR_DEBUGGING=0 define. This might significantly lower performance of your debug build if you are using STL heavily in time-critical code. As such a define is not present by default, I suppose that whoever added it did that for a good reason (just like me).

2) Switch your debug configuration to use "Multithreaded Debug" runtime (i.e. link CRT statically). Since you are probably only using debug configuration for development and in-house debugging, this should not cause any problems. You can keep the shared runtime for release configuration (since you probably can't debug it properly anyway).

Note that both solutions would also require adjusting the corresponding setting in ALL of your dependencies (static/dynamic libraries) and rebuilding them, otherwise you won't be able to link to them anymore.