The problem with"grep" is that it doesn't understand what it is parsing,
and if you are looking for the definition of a often used symbol, you
will have to waste a lot of time looking at all occurrences of the
symbol until you find the definition.
I usually don't.
If I want to find the definition of struct foo, 'grep "struct foo {" ...'
does fine by me.
But grep is OK for people that use vim and printf debugging. Just go
ahead. Why do something automatically if you can do it by hand?
Heh.
Actually, there are things for which printf debugging is extremely useful.
For instance, let's say you have something which fails about one time
in a million. Which is faster:
1. Setting a breakpoint at the beginning of the operation, and stepping
through it each time to see how it failed.
2. Setting up logging and looking at the previous few log messages
before the failure.
But at each line, you have to type:
print"xxx" to figure out what is the value in variable "xxx".
And if you setup a watch you will have to unset it soon and set
another watch as variables getting used change.
I haven't had much trouble with that. For that matter, I don't usually
print a variable each line; I print it only when I think it's at risk of
changing.
I mean the ability to continue the exection at any line in the
current function. Apparently you have never used that feature of
gdb. No wonder you do not miss it in ddd.
I can't conceive of using that. If I'm not at the line, continuing there
wouldn't be relevant to what the program does outside the debugger anyway.
-s