Re: STL containers

[Jason Molenda <jmolenda at apple dot com>]

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