Re: -stack-list-locals and children

["André Pönitz" <andre.poenitz@nokia.com>]

On Monday 29 June 2009 11:39:27 Vladimir Prus wrote:
> > One point was always to reduce the number of roundtrips before
> > being able to display the variable view. I think that's a valid point
> > also from a KDevelop angle of view.
> 
> Right, but how variable type is helping? Is it used *just* to populate
> the "type" field in variable view? Or is it also involved in QtCreator's
> pretty-printing mechanisms somehow?

Right. They are also primary information for the current incarnation of
Qt Creator's pretty-printing. 

However I don't want center the argumentation around the needs of 
a specific IDE though if there is a "cross-IDE" reason. And reducing
roundtrip count should be fairly cross-IDE ;-}

> >> One important question is whether knowing a type of expression, without
> >> knowing its address, is gonna help you very much.
> > 
> > Yes, as the address is not as prominently displayed in the view as the
> > type having the type quickly even without an address would help.
> 
> But will address help if the object being displayed needs pretty-printing?
> Say, QString? I am not actually sure how you do pretty printing, but I'd imagine 
> that address should always be needed.

I get the address filled in "for free" by gdb when invoking the pretty printers.
It's conceptionally[1] something like  running "call dumpQString(&astring)"
through gdb when there is a local "QString astring;" in the code.

So I don't have a specific interest in having the address available in the 
first round.However, in general I would not mind if information that's easily 
available  on the gdb side and that takes only a few characters would be 
output. So if you added an address field I'd certainly not complain ;-)

Andre'

[1] In practice it's way more messy as this needs to work with several 
versions of gdb (and other debuggers for that matter)