Reputation: 22493
From googling around it looks like Xcode (3.1 in my case) should be at least trying to give me a sane debug view of STL containers - or at least vectors.
However, whenever I go to look at a vector in the debugger I just see M_impl, with M_start and M_finish members (and a couple of others) - but nothing in-between! (it's a debug build, btw).
Am I missing a setting or something somewhere?
I've also read that there are macros available that can augment the debug viewer even further to inspect more complex containers - but have been unable to find any.
I'd also like to be able to view std::wstrings, without having to drop to the memory viewer. It shows std::string fine. Is there anything I can do to show std::wstring?
I realise this is a bit of a composite question - but it's all really part of the same subject.
Upvotes: 7
Views: 5252
Reputation: 6809
You can create Data formatters for different variable types so they show up nicer :-).
Upvotes: 2
Reputation: 333
Try using the GDB debugger in Project->Edit Scheme... and consider switching your compiler to LLVM GCC 4.2 in the Project Build Settings (under Build Options -> Compiler for C/C++/Objective-C).
In XCode 4, I found I needed these settings to view things like a std::vector of V3f where V3f is a templated float vector type.
Note that I think you can't use ARC (Automatic Reference Counting) with LLVM GCC 4.2.
Upvotes: 1
Reputation: 1492
The ability to view the container's items may rely on the complexity of the templated type. For trivial objects like int, bool, etc., and even simple class templates like
template <class T> struct S { T m_t; }
I normally have no problem viewing vector items in the debugger variable view. I say normally because there seem to be occasional bugs that cause stuff--particularly when debugging--not to behave the way I expected. One of those things is garbage or totally useless information in the variable view. Usually a clean rebuild of the target (or sometimes even a more drastic restarting of XCode followed by a clean rebuild) fixes the problem.
As for the other container types, it's most likely hard to efficiently view this information. For example a map is often implemented as a red-black tree. The debugger would have to know that in advance in order to properly walk the tree and show you all the keys and values. That's probably asking a lot from Xcode or GDB--especially since the former focuses more on Objective-C and plain C than C++ (hence the fact that namespaces tend to kill code completion despite their ubiquity and importance).
Upvotes: 1