Re: variable objects and registers

[Vladimir Prus <ghost at cs dot msu dot su>]

On Friday 22 December 2006 07:42, Nick Roberts wrote:
>  > Sadly, neither Jason nor I will get a chance to do anything other  
>  > that our already scheduled tasks till we're done with Leopard -  
>  > sometime middle of next year or thereabouts.  We have a lot on our  
>  > plates till then, and don't have any time available for this.  I  
>  > can't really say what our plans will be after that.
> 
> OK, well thanks for the pointers anyway.
> 
>  > >> Another kind of useful addition along the same lines, we extended the
>  > >> "FRAME" argument to -var-create so you can say:
>  > >>
>  > >> -var-create - +main.c:6 bar
>  > >>
>  > >> to create the variable object for bar in the scope surrounding line
>  > >> 6.  This is necessary if you want to do variable values in tooltips
>  > >> using variable objects.
>  > >
>  > > Yes, I see Insight uses variable objects for tooltips too.  What  
>  > > advantage do
>  > > they have over just using "print"?
>  > 
>  > The Xcode tooltips allow structure expansion & formatting the same  
>  > way the locals display does.  Using varobj's for this makes the code  
>  > uniform, and simpler.
> 
> Insight just prints the type as a tooltip for structures.  You seem to be
> saying that in Xcode you can do this and choose to expand it.  Using "print"
> in Emacs, everything is automatically expanded which I must admit is messy
> with a large array or structure.  Perhaps -data-evaluate-expression could
> be modified to print "--simple-values" or "--all-values" as -stack-list-locals
> does.

I think it's much better to use varobjs for tooltips. It's much better for structures.

> Actually I see Insight gets it wrong, when one variable masks another with
> the same name, just printing the current value.  I guess variable objects
> allow such values to be correctly accessed, but they generally they seem
> to be designed for tracking values rather than getting instantaneous ones
> as with tooltips.

There's no reason why -var-create cannot be extended to also specify line
at which the expression must be evaluated -- computing the right block.

- Volodya