This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pretty-printing update


On Tuesday 07 October 2008 01:23:28 Tom Tromey wrote:
> Daniel> Sorry for coming down on you about this; it's not directed just at
> Daniel> you, but at most front end developers.  Don't work around GDB!  Tell
> Daniel> GDB what you need, instead, and work with it.
> 
> I completely agree.
> 
> Furthermore -- send your wish list now.  At least, your varobj and/or
> pretty-printing wish list.

Let's start with varobjs. That's simple: I don't think they are as useful for
C++ as they are for C. So far I never _needed_ the magic creation
of child objects corresponding to the "physical members" of the struct
but rather "logical members". As example: I my world, most classes use
the "pointer-to-implementation" idiom, and displaying the "pimpl" would
just clutter the the view, so I want to have the physical members of the
the pimpl of the object be displayed as "logical children" of the object.
In other cases I want to treat temporary objects returned by calling
certain member functions as "child". Sometimes I want to display a single
physical entry (say, a time stamp) as several children (e.g. to have the
ability to see the Greenwich time "value" and local time "value" 
simultaneously). And so on.

I also do not need the private/protected/public "dummy" children created
right now. In fact, they are rather annoying. Nobody really cares for access 
rights when debugging, at least not to a degree rectifying an additional 
level in the tree view. At most, an additional data field for the member
might be interesting. We had this discussion already a while ago.

I cannot use -var-update since it can produce an unpredicatable amount of 
data in its current incarnation.I have to extract enough data to fill a few 
dozen lines in a treeview.
I can do that easily in each step by piping a few dozen commands into 
gdb. Performance is acceptable, and the approach is robust. I am happy 
with that. So no matter how -var-update might be improved, I have no real
reason to use it.

With -var-update not used, there is no much value in having varobjs at all,
the usage boils down to  create-evaluate-delete  cycles, and for that "one 
shot functions" would be easier. There are basically only two such operations
I really need, for both traditionally output and "prettyprinting" [And I think
they are generic enough to be of general utility]:

 1. "-describe-expression <expr> <type>" 
    Take an expression and a "type" and give me:
    - the "real" value (possible "{...}" if too complex)
    - if (there is a pretty printer for type) {
       - a "pretty printed" "short value"
       - the number of items the pretty printer considers as "children"
     } else {
       - the number of members in the struct
     }
   
  2. "-describe-children <expr> <type>" 
     Take an expression and a "type" and give me:
     - if (there is a pretty printer for type) {
          for each item that the pretty printer considers a "child":
            - an expression
            - a "type"
       } else { 
          for each member in the struct:
            - an expression specifying this member
            - its type
       }

A "type" may either be a real type or an artifical one, specified by a name. 
Pretty printers can be installed for real types and artifical ones.

The artificial types allow to build up structures on the client side that
are not physically present somewhere in memory, or not an instance
of a (locally available) object. Think of displaying the contents of a
database: The values are the result of a query (the "expression").
Or display a container (say, an array), as something different (say, a heap),
or even have both views simultaneously.

> FWIW: one reason that I think it is preferable to come up with a
> shared pretty-printing solution is because it is the best way to scale
> to having pretty-printers shipped for many libraries and programs.

I don't think there is need to invest much effort in such shared solutions, 
probably because my expectation on the number of prettyprinters that will
be created in the next decade differs from yours by a few orders of
magnitude ;-)

Predicting the future is notoriously hard, but I have one data point from the
past that might help extrapolation: Debugging applications based on libraries
built of more than 3000 classes gets significantly simpler with the help of
about 20 pretty printers (including a few for "artifical" types). Now, this is
biased because in this case a lot of the classes are in a single-inheritance
hierarchy with some of the prettyprinters dedicated to "proper display" of the 
base class, yielding usable results for most derived classes. But even in a 
value-based world like the Standard containers, a dozen pretty printers will
be a huge and possibly sufficient improvent. So I would bet there won't ever
be more than a few hundred prettyprinters world wide, no matter how 
convenient sharing is.

Andre'


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]