Type information in -data-evaluate-expression

[André Pönitz]

On Monday 30 July 2007 15:52:10 Vladimir Prus wrote:
> André Pönitz wrote:
> > While playing around with gdb's "mi" interface (which looks rather
> > nice for scripting btw...) I came across a few places where I think
> > the interface might be made even more convienient without much
> > effort.
> > 
> > One example: As far as I can see currently the only way to obtain
> > the type of an expression is to use -var-create & -var-delete.
> > It would be more convienient for me if I could get that information
> > with a single command without creating a variable which will be
> > thrown away immediatedly afterwards.
> 
> What is the use case where you need to just get the type of an expression,
> without doing anything with it?

One use case would be to display values in a graphical frontend
when hovering (or even moving) the mouse over some expression.
My current "best practice" here is to create a variable called "tooltip",
extract value and type and delete it again, only to create it again
with a slightly different expression etc. So I need two roundtrips
and need some syncronization to handle the two partial results
whereas the proposed "enhanced" version would allow a simple
hit-and-run implementation...

Also, there are times when I would like to call "custom data dumpers"
(think std::string or std::vector) instead of using the content of the 
value field. To trigger those dumpers quickly I need to get hold of type
information quickly, preferably after the first round trip. I understand that
a delay of a few dozen milliseconds for a round trip is a non-issue for
the typical command line use, however these add up easily to a more
significant amount if one "needs" lots of them...

> [...] I'd expect this patch will break a bunch of tests, since those tests
> are not expecting the additional 'type' field. 

mi2-eval.exp and mi-eval.exp seems to be affected, I guess I would
be able to fix them.

> The patch itself seems reasonable as far as code is concerned, but
> I'm not yet sure about your use case.
> I'd prefer -data-evaluate-expression to fall to misuse, 
> rather than adding some new functionality to it.

The gdb variable business requires some bookkeeping on the frontend
side some of which I'd like to avoid.

Andre'