Vladimir Prus <ghost@cs.msu.su> writes:
Suppose I'm stopped where the stack is like this:
main -> foo (2) -> foo (1) -> foo (0)
Suppose the top frame is selected, and the user adds a display for
'x'. Clearly, it should show '0'.
You're using an ill-defined term "adds a display".
Well, sure. I'm asking people to tell me about all the GUIs they work
on, so I can't use specific language.
4) If the user lets control run to 'foo' again, so the stack now
looks
like:
main -> bar (10) -> foo (9)
what should happen to the display of 'x'? (I'd say it should show
'9'.)
I agree.
I think that @-variable-object should behave as described above.
Right; I wasn't aware of '@'-frame varobjs when I originally wrote,
since they're not documented.
Note also that it's possible to imagine GUI commands that show a
value of some expression in particular "scope", and became
forever grayed out when that scope dies. It raises numerous
questions how to identify scopes. It should be noted that KDevelop
does not have such UI command, and it was never requested.
Yeah, it doesn't seem too useful.
The principle behind my guesses is that a display should refer to a
particular variable in the source code --- a particular declaration
--- and should show its value whenever that declaration is in
scope in
the selected frame. This is less specific than having the display
refer to a particular frame's instance of that variable, and more
specific than having it refer to any variable that happens to be in
scope under that name. But it's what I'd expect from a GUI.
This seem to contradict your claim that in 'bar', we should show '9'
for 'x' -- it's different 'x', after all.
You misread --- I said we should show '9' in the first call to foo
from bar.
Assume user asked to show value of "x+y". There are three
alternatives:
1. Show value of that expression in specific frame, gray it out
otherwise.
2. Show value of that expression in current frame, provided "x" and
"y"
refer to the same language declaration.
3. Show value of that expression in current frame.
(3) is what implemented by @-varobjs. You seem to propose (2),
which will only differ from (2) by the fact that sometimes (3) will
show
a value and (2) will have value greyed. Is this big enough deal to
worry about?
Yes, that is the distinction. If it's not important to GUI
implementors, then it's certainly not a big enough deal to worry
about.
As for (1), it's implemented by ordinary varobjs.
Except for the frame collision behavior which I demonstrated, yes.