STL containers

STL containers

[Przemyslaw Sliwa]

All,

Is it possible to display a content of the STL containers by gdb?
I have a class with a member of type std::vector<std::valarray <double> >.
If I try to display the contents of the vector I see only the address of
the begin and the end of the vector. And what about the contents of the
valarrays?

If it is not possible is there any free debugger which allows this?

Thanks for help

Przem

STL containers

[Przemyslaw Sliwa]

All,

Is it possible to display a content of the STL containers by gdb?
I have a class with a member of type std::vector<std::valarray <double> >.
If I try to display the contents of the vector I see only the address of
the begin and the end of the vector. And what about the contents of the
valarrays?

If it is not possible is there any free debugger which allows this?

Thanks for help

Przem

Re: STL containers

[Jason Molenda]

On Jul 15, 2004, at 12:05 PM, Przemyslaw Sliwa wrote:

> Is it possible to display a content of the STL containers by gdb?

In the Apple integrated development environment (Xcode), we handled 
this in two ways.  One, we added a "print for debugger" class to many 
of the standard Objective-C classes, and two, our UI has a "custom data 
formatters" feature.

For objects supporting the "print for debugger" method, we have a 
"print-object" or "po" command in gdb which invokes taht method on a 
given object.  The print for debugger methods prints the object's 
contents to stdout in some human-meaningful way.

For the custom data formatters, our debugger UI comes with a bunch of 
pre-canned formatters.  For a simple structure, like a structure that 
represents the height and width of a rectangle (with structure data 
member names "height" and "width"), you'd write width=%width%, 
height=%height%, and in the UI the variable summary field looks like 
"width=100, height=150".  gdb is just grabbing the children of a varobj 
- very fast.

The custom data formatters also allow you to make inferior function 
calls to extract information from objects that don't have a simple 
representation.  We provide these custom data formatters for the main 
classes in our graphics frameworks.  We don't provide them for STL yet, 
but the point of this feature was that it'll be easy to add them for 
STL classes in the future as well.  (and users can easily write their 
own custom data formatters for STL or their own classes).

Unfortunately I don't think either of these approaches will help you 
much.  The "print for debugger" method requires collaboration with the 
library provider.  The "custom data formatters" method requires a lot 
of work in a debugger UI sitting above gdb.  I don't think it makes 
much sense to try to put these kinds of facilities directly inside gdb, 
but that's just MHO.

(in case anyone is wondering, yes, having lots of custom data 
formatters doing inferior function calls does slow down stepping speed. 
  They are easily disabled in the UI and we encourage people to do so 
when they've got too many locals being formatted at each step.)


J