automated cast to different data type possible?

automated cast to different data type possible?

[Klaus Rudolph]

Hi all,

I have the following data structures:

class Base
{
enum Type
{
TYPE_A,
TYPE_B,
...
} type;

public:
  Base(Type _type):type(_type){}
 };

class A: pubic Base {

   int x;
   int y;
   ptr ...

public:
   A():Base(TYPE_A){}

};

class B: public Base {
   B():Base(TYPE_B){}
   double a;
   double b;
   int c;
   ptr ...
   ptr ...
};

Base* ptr1=new A;
Base* ptr2=new B;

---------

Now I want to debug ptr1. print returns only the output for base. OK
But I want to see, the type is a object of class A.
Writing a pretty printer for Base is possible and could output
as a type of A or B which works fine.

BUT! and that is the my question:
The pretty printer only give an output which "looks like" a type of A or B.
In combination with ddd I am not able to dereference the ptr pointers in A or B, because the object of type Base contains no ptr element!

On command line:
graph display ptr1;
<double click on ptr1> -> 
graph display *ptr1
a new window in graph view is visible with type Base
if I have a pretty printer inserted, I get a output which looks like
an object of class A.
But: if I now do a <double click> on the ptr elements, I got:
no element ptr... in Base.

Is there any chance to handle that kind of automatism in a python script?
To make the classes virtual is no solution, the data structure is fixed and used for persistent storage.

Thanks
 Klaus









-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!			
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: automated cast to different data type possible?

[Tom Tromey]

>>>>> "Klaus" == Klaus Rudolph <lts-rudolph@gmx.de> writes:

Klaus> Base* ptr1=new A;
Klaus> Base* ptr2=new B;

Klaus> Now I want to debug ptr1. print returns only the output for base. OK
Klaus> But I want to see, the type is a object of class A.

You want "set print object on".

Tom

Re: automated cast to different data type possible?

[Klaus Rudolph]

Tom Tromey wrote:


> Klaus> Base* ptr1=new A;
> Klaus> Base* ptr2=new B;
> 
> Klaus> Now I want to debug ptr1. print returns only the output for base.
> OK
> Klaus> But I want to see, the type is a object of class A.
> 
> You want "set print object on".

This only works with classes which includes a vtable, but there is no virtual function inside that hierarchy.

regards 
 Klaus 
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: automated cast to different data type possible?

[Tom Tromey]

>>>>> "Klaus" == Klaus Rudolph <lts-rudolph@gmx.de> writes:

Tom> You want "set print object on".

Klaus> This only works with classes which includes a vtable, but there
Klaus> is no virtual function inside that hierarchy.

Sorry about that; you even noted this in your original message and I
missed it.

Pretty-printers just change how a value is displayed.  They don't change
the type.  I am just guessing that this is the problem -- I don't know
anything about DDD.  If this is incorrect, I suggest asking the DDD
developers.

Tom

Re: automated cast to different data type possible?

[André Pönitz]

On Thursday 12 May 2011 18:05:13 ext Tom Tromey wrote:
> >>>>> "Klaus" == Klaus Rudolph <lts-rudolph@gmx.de> writes:
> 
> Tom> You want "set print object on".
> 
> Klaus> This only works with classes which includes a vtable, but there
> Klaus> is no virtual function inside that hierarchy.
> 
> Sorry about that; you even noted this in your original message and I
> missed it.
> 
> Pretty-printers just change how a value is displayed.  They don't change
> the type. [...]

Assuming that I understood the task correctly it can be done with 
gdb python scripting nevertheless.

Given

    struct KRBase
   {
      enum Type { TYPE_A, TYPE_B } type;
      KRBase(Type _type) : type(_type) {}
   };

   struct KRA : KRBase { int x, y; KRA() : KRBase(TYPE_A), x(1), y(32) {} };
   struct KRB : KRBase { KRB() : KRBase(TYPE_B) {}  };

   void testKR()
   {
      KRBase *ptr1 = new KRA;
      KRBase *ptr2 = new KRB;
      break_here();
  }

creating a display of 

	ptr1	 @0x809a9d0	KRA
		KRBase		KRA
		x	1	int
		y	32	int
	ptr2	 @0x809a9e0	KRB
		KRBase		KRB

takes three lines of python code:

   def qdump__KRBase(d, item):
       base = ["KRA", "KRB"][int(item.value["type"])]
       d.putItem(Item(item.value.cast(lookupType(base)), item.iname))

[using, admittedly, the *cough* "other" approach to pretty printing]


Andre'

PS: I put a real screenshot at 
  
  http://imageshack.us/photo/my-images/135/kr2e.png

as I am not sure how acceptable attaching a 15k .png is on this list.

Re: automated cast to different data type possible?

[Klaus Rudolph]

André Pönitz wrote:

> 
> Assuming that I understood the task correctly it can be done with 
> gdb python scripting nevertheless.
> 
> Given
> 
>     struct KRBase
>    {
>       enum Type { TYPE_A, TYPE_B } type;
>       KRBase(Type _type) : type(_type) {}
>    };
> 
>    struct KRA : KRBase { int x, y; KRA() : KRBase(TYPE_A), x(1), y(32) {} };
>    struct KRB : KRBase { KRB() : KRBase(TYPE_B) {}  };
> 
>    void testKR()
>    {
>       KRBase *ptr1 = new KRA;
>       KRBase *ptr2 = new KRB;
>       break_here();
>   }
> 
> creating a display of 
> 
> 	ptr1	 @0x809a9d0	KRA
> 		KRBase		KRA
> 		x	1	int
> 		y	32	int
> 	ptr2	 @0x809a9e0	KRB
> 		KRBase		KRB
> 
> takes three lines of python code:
> 
>    def qdump__KRBase(d, item):
>        base = ["KRA", "KRB"][int(item.value["type"])]
>        d.putItem(Item(item.value.cast(lookupType(base)), item.iname))
> 
> [using, admittedly, the *cough* "other" approach to pretty printing]

Sorry,

please give me an idea who is calling qdump_KRBase and what is parameter
d? I actually have no idea how to add that to the printer script... or
maybe any other python script to gdb.

Thanks
 Klaus

Re: automated cast to different data type possible?

[André Pönitz]

On Sunday 15 May 2011 16:20:00 ext Klaus Rudolph wrote:
> André Pönitz wrote:
>
> > Assuming that I understood the task correctly it can be done with 
> > gdb python scripting nevertheless. [...It] takes three lines of python code:
> > 
> >    def qdump__KRBase(d, item):
> >        base = ["KRA", "KRB"][int(item.value["type"])]
> >        d.putItem(Item(item.value.cast(lookupType(base)), item.iname))
> > 
> > [using, admittedly, the *cough* "other" approach to pretty printing]
> 
> Sorry,
> 
> please give me an idea who is calling qdump_KRBase and what is parameter
> d? I actually have no idea how to add that to the printer script... or
> maybe any other python script to gdb.

The code would be called from a Python script that creates the full
display for an local variable including all expanded children in one go. 
'd' is an object that accumulates output that's finally 'printed', and
takes care of properly closing nested items in case of exceptions.

The approach is different from the one taken by the "official" pretty 
printers, but also uses gdb's python scripting. Since this approach
gives access to all levels of the hierarchy at one time, re-arranging
items or re-writing parts of the "parent" items (like in your case the 
name of the type) is straightforward.

Andre'

Re: automated cast to different data type possible?

[Klaus Rudolph]

André Pönitz schrieb:

>> please give me an idea who is calling qdump_KRBase and what is parameter
>> d? I actually have no idea how to add that to the printer script... or
>> maybe any other python script to gdb.
> 
> The code would be called from a Python script that creates the full
> display for an local variable including all expanded children in one go. 

Is there any interface defined for that purpose? Or you think that I
should create a new gdb command? If I handle that from a new gdb
command, there is really no problem, but that fits not in the
integration to ddd without changing sources of it.

> 'd' is an object that accumulates output that's finally 'printed', and
> takes care of properly closing nested items in case of exceptions.
> 

Is there any description which can handle such idea? Maybe you already
have such a solution finsihed? Maybe there is also an official one but
not known by me?

Regards
 Klaus

Re: automated cast to different data type possible?

[André Pönitz]

On Monday 16 May 2011 19:18:35 ext Klaus Rudolph wrote:
> André Pönitz schrieb:
> 
> >> please give me an idea who is calling qdump_KRBase and what is parameter
> >> d? I actually have no idea how to add that to the printer script... or
> >> maybe any other python script to gdb.
> > 
> > The code would be called from a Python script that creates the full
> > display for an local variable including all expanded children in one go. 
> 
> Is there any interface defined for that purpose? Or you think that I
> should create a new gdb command? If I handle that from a new gdb
> command, there is really no problem, but that fits not in the
> integration to ddd without changing sources of it.

The necessary basic interface is gdb's python module, i.e.

  http://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html#Python-API

The script on top of that would be something similar to

  https://qt.gitorious.org/qt-creator/qt-creator/blobs/master/share/qtcreator/gdbmacros/dumper.py

This also contains definitions of convenience functions that uses that scheme.
Some example pretty-printer implementations using that scheme are in 

  https://qt.gitorious.org/qt-creator/qt-creator/blobs/master/share/qtcreator/gdbmacros/gdbmacros.py

The qdump__KRBase() function I mentioned is currently at the end of that file.

The main script produces gdb/MI-style output. I am not sure whether ddd 
can digest that, if not, producing "human readable" output by "fixing" the 
put*() methods in the Dumper class should be straightforward. 

> > 'd' is an object that accumulates output that's finally 'printed', and
> > takes care of properly closing nested items in case of exceptions.
> 
> Is there any description which can handle such idea? Maybe you already
> have such a solution finsihed?

I have, Qt Creator uses this approach. There are some hints on what it does 
and how it works (I wouldn't call it "documentation", though) at

  http://doc.qt.nokia.com/qtcreator-snapshot/creator-debugging-helpers.html

> Maybe there is also an official one but not known by me?

I don't think so.

Regards,
Andre'