Print option in debugger

[Andreas Pakulat]

On 28.02.07 12:24:55, Leon Pollak wrote:
> On Wednesday 28 February 2007, Andreas Pakulat wrote:
> > On 27.02.07 17:07:34, Leon Pollak wrote:
> > > Independently of the version, I should like to suggest to add to the
> > > right click menu option "print variable" (as it is done in DDD.
> > > This is very useful option, especially in the case when we do not have in
> > > kdevelop possibility to hoover with cursor over variable and see its
> > > value. This is because options "evaluate" and "watch" are more "solid",
> > > while many times one needs to look at some variable once only.
> >
> > I don't really understand, print <variable> issued to the debugger
> > wouldn't show you the variable value unless its a built-in C type, i.e.
> > char*, int and such thing. And those are available using the value tree
> > already. So IMHO there's no point in having that print option.
> >
> > Andreas
> If I understand you correctly, the "value tree" is that appears in the 
> variable window?

Yes.

> If yes, then how some variable appears there?

All variables that gdb reports are shown there, or what do you mean?
Including their respective value if gdb knows how to create that value.
So if there's a variable that doesn't show up there, gdb doesn't return
it when asked for the currently available variables. 

> By right clicking on it in the 
> source window and choosing "evaluate" or "watch"? And thus it stays there 
> forever. And if I choose "evaluate" it stays and makes me think that this is 
> the value, which may already be changed. And to remove it, I must choose the 
> menu...

Right, but thats the purpose of that command. Evaluate evaluates the
value of a variable and does so only once. Watch should update the value
if it changes.

> Contrary, typing in the gdb console "p X" in 99% of the cases does the work.

Then you're only working with char*, int and co. Not with stuff like
std::list, QString, QList and others.

> What I meant in my first mail is to pass to the gdb simple command "p X", 

I did understand that.

> where X is the variable under the cursor. And gdb knows very well which type 
> is X. And it needs not be only the built-in C, as you mentioned. It knows all 
> the types, classes, enums, defines, etc. defined in the executable.

Yes it knows the type, but knowing a given type doesn't tell it how the
type has to be printed. For example for QString you have to fetch a
specific internal member variable to get to the actual value and also
process that value a bit.

Andreas

-- 
You are sick, twisted and perverted.  I like that in a person.