This is the mail archive of the
mailing list for the GDB project.
Re: [rfc] xfailed tests in gdb.c++/classes.exp
- From: Jason Molenda <jmolenda at apple dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: carlton at math dot stanford dot edu, drow at mvista dot com, gdb at sources dot redhat dot com
- Date: Fri, 28 Feb 2003 12:56:57 -0800
- Subject: Re: [rfc] xfailed tests in gdb.c++/classes.exp
I like to pull mail threads utterly off-topic whenever possible:
On Thursday, February 27, 2003, at 07:51 PM, Michael Elizabeth
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
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.