Re: [rfc] xfailed tests in gdb.c++/classes.exp

[Jason Molenda <jmolenda@apple.com>]

I like to pull mail threads utterly off-topic whenever possible:

On Thursday, February 27, 2003, at 07:51  PM, Michael Elizabeth 
Chastain wrote:

> If you look in gnats, you will see users complaining that they can't
> print their string variables (because C++ strings are implemented with
> layers of templates and derived classes).  They are complaining that
> operator overloading doesn't work.  They are complaining that they have
> a std::vector<Foo> and they can't even look inside the damn thing.

We have the same problem here at Apple, introspecting objects.  As a 
convention, many of the standard Cocoa Objective C classes include a 
"NSPrintForDebugger" member function which can print the object in some 
way that is meaningful to the developer.  We have a gdb command, 
"print-object" or "po" which does an inferior function call into this.  
In the GUI, we let users right-click on locals et al and do this 
command.  It's not fancy/seamless/beautiful, but it is enough for users 
to do what they need.  It does depend on support from the class 
libraries, obviously.

That's still not ideal - your Locals window still shows a bunch of 
variables with raw pointers instead of the strings they contain.  Rab 
Hagy added a feature last summer to display these objects as strings 
when using the ProjectBuilder GUI.  He added a solib that is loaded 
into the inferior to provide some object introspection functions in the 
inferior executable, and at a stop he determines if an object is an 
NSString class or inherited from that class, and then gets the 
formatted version of that text.

This approach is very expensive (making an inferior function call for 
each local object for each step) so we'll surely need to refine it in 
the future, but it's a step in the right direction.


Well, Rab could provide better details on what he did and where he sees 
this going (I was utterly uninvolved), but we're looking at these same 
problems here at Apple.  We haven't cracked into the C++ library yet, 
but the problems are of a similar sort.

J