Re: Type information in -data-evaluate-expression

[Vladimir Prus <ghost@cs.msu.su>]

André Pönitz wrote:

> 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...

Yes, but in the long run, your frontend will need a mechanism to
handle chain of several commands, anyway. In fact, I think the best
design would be to talk to gdb in a separate thread, so that
you need a straight-forward procedural code, not callback-based code.
At least, that's the design I plan to use in KDevelop4.

> 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...

If you query the type for expression under cursor, then you have only one
expression, no? Therefore, the difference between 1ms and 2ms is not important.

- Volodya